7-0-saa-sys-man-guide-pdf-free

Connectivity Alliance Access 7.0.20 System Management Guide This system management guide explains how to configure and manage Alliance Access. The document is mandatory reading for Alliance Access administrators and other personnel who set up and configure the essential components of Alliance Access. 15 July 2011 Alliance Access 7.0.20 Table of Contents .Preface .............................................................................................................................................................................9 Part A – Introduction ........................................................................................................................................11 1 Understanding the Basics ......................................................................................................................... 13 1.1 1.2 1.3 1.4 2 The Alliance Access Options ................................................................................................................. 13 Signing on to Alliance Access ............................................................................................................... 13 The Access Control Window ................................................................................................................. 15 The File Menu .......................................................................................................................................... 17 Using Applications ....................................................................................................................................... 24 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Running Applications .............................................................................................................................. 24 Standard Menus ...................................................................................................................................... 27 Shortcut Menus ....................................................................................................................................... 29 Printing Reports ....................................................................................................................................... 30 Printing Messages ................................................................................................................................... 31 Entering Dates and Times ..................................................................................................................... 32 Sorting Items ............................................................................................................................................ 32 Rearranging Columns ............................................................................................................................. 33 Selecting a File ........................................................................................................................................ 35 Part B – Housekeeping Tasks ..................................................................................................................37 3 Installing the SWIFT Alliance Bank File .............................................................................................. 39 3.1 3.2 3.3 3.4 3.5 3.6 4 Installing Message Syntax Tables ......................................................................................................... 46 4.1 4.2 5 Creating Logical Terminals .................................................................................................................... 49 Assigning a Message Syntax Table ..................................................................................................... 50 Selecting the Window Size .................................................................................................................... 51 Automatic Logical Terminal Allocation ................................................................................................. 52 Managing the MX Message Standards ................................................................................................ 54 6.1 6.2 6.3 2 Message Syntax Tables ......................................................................................................................... 46 Setting a Default Message Syntax Table ............................................................................................ 47 Creating and Configuring Your Logical Terminals ........................................................................ 49 5.1 5.2 5.3 5.4 6 Alliance Bank Files .................................................................................................................................. 39 Options for Installing an Alliance Bank File ......................................................................................... 39 What Happens During Bank File Installation ...................................................................................... 41 Download an Alliance Bank File ........................................................................................................... 42 Install an Alliance Bank File Immediately ............................................................................................ 43 Loading the Bank Files from Disk ......................................................................................................... 44 Viewing and Printing MX Message Standards ................................................................................... 54 Install an MX Message Standard .......................................................................................................... 55 Remove an MX Message Standard ..................................................................................................... 56 System Management Guide Table of Contents 7 8 Installing Value-Added Services ............................................................................................................ 57 7.1 FINCopy Service ..................................................................................................................................... 57 7.2 7.3 7.4 7.5 Installing and Removing Value-Added Service Parameter Files ..................................................... 59 Activating and Deactivating Value-Added Services ........................................................................... 61 Assigning a Value-Added Service to a Destination ........................................................................... 62 Value-Added Service Destinations Window ....................................................................................... 63 Assigning Routing Keywords ................................................................................................................. 65 8.1 9 Procedure for Assigning Routing Keywords ....................................................................................... 65 Modifying Active Routing Rules ............................................................................................................. 67 9.1 About Modifying Active Routing Rules ................................................................................................. 67 Part C – Configuring Alliance Access ................................................................................................69 10 Starting, Stopping, and Restarting the Servers .............................................................................. 71 10.1 10.2 10.3 10.4 10.5 10.6 11 Housekeeping Mode and Operational Mode ...................................................................................... 71 Starting the Alliance Access Servers ................................................................................................... 72 Stopping the Alliance Access Servers ................................................................................................. 72 Restarting the Alliance Access Servers ............................................................................................... 73 Extended Reporting at Startup of Alliance Access ............................................................................ 74 Stopping and Restarting Components ................................................................................................. 74 Managing Alliance Access Security ..................................................................................................... 77 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 11.10 11.11 11.12 11.13 11.14 11.15 11.16 11.17 11.18 11.19 11.20 11.21 15 July 2011 Listing Components ................................................................................................................................ 77 Defining Units ........................................................................................................................................... 78 Operator Profiles ..................................................................................................................................... 80 Modifying Operator Profiles ................................................................................................................... 83 Adding New Operator Profiles ............................................................................................................... 84 Predefined Operators and New Operators ......................................................................................... 85 Defining Operators .................................................................................................................................. 85 Setting Up Local Security Officers ........................................................................................................ 88 Approving and Enabling Operator Definitions .................................................................................... 90 Modifying Operators ............................................................................................................................... 92 Listing Operators ..................................................................................................................................... 93 Creating Operator and Profile Details Reports ................................................................................... 97 Disabling Operators ................................................................................................................................ 98 Removing Operators ............................................................................................................................... 99 Resetting Operator Passwords ............................................................................................................. 99 Resetting Security Officer Passwords ............................................................................................... 100 User Access Security ........................................................................................................................... 101 Modifying Security Parameters ........................................................................................................... 101 Security Parameter Details Window ................................................................................................... 110 Restricting Operator Functions ........................................................................................................... 112 Configuring Authentication Servers .................................................................................................... 113 3 Alliance Access 7.0.20 12 SWIFTNet Security ..................................................................................................................................... 121 12.1 For MT Messaging ................................................................................................................................ 121 12.2 For MX Messaging ................................................................................................................................ 122 13 Defining Printers (UNIX only) ................................................................................................................ 123 13.1 Viewing Existing Printer Details .......................................................................................................... 123 13.2 Device Details Window (UNIX only) ................................................................................................... 123 13.3 Defining New Printer ............................................................................................................................. 124 14 Installing Application Services Profiles ............................................................................................ 126 14.1 About Application Service Profiles ..................................................................................................... 126 14.2 Install an Application Service Profile .................................................................................................. 127 15 Defining SWIFTNet Profiles .................................................................................................................... 128 15.1 15.2 15.3 15.4 15.5 16 Set up SWIFTNet Profiles .................................................................................................................... 128 Assigning SWIFTNet Connections to SWIFTNet Profiles .............................................................. 134 Enabling and Activating SWIFTNet Profiles ..................................................................................... 139 Set Up Input Channels ......................................................................................................................... 140 Set Up Output Channels ...................................................................................................................... 145 Configuring SWIFTNet Connections .................................................................................................. 148 16.1 About the SWIFTNet Support Application ......................................................................................... 148 16.2 Defining and Modifying SWIFTNet Connections .............................................................................. 149 16.3 Assigning SWIFTNet Connections to a Logical Terminal ............................................................... 155 17 Configuring System Parameters .......................................................................................................... 158 17.1 Modifying Parameters ........................................................................................................................... 158 17.2 Configuration Details Window ............................................................................................................. 159 17.3 Classes of Configuration Parameters ................................................................................................ 159 18 Configuring Event and Alarm Distribution ...................................................................................... 171 18.1 18.2 18.3 18.4 19 Event Distribution .................................................................................................................................. 171 Alarm Distribution .................................................................................................................................. 178 Printing Reports ..................................................................................................................................... 184 Alarm Scripts .......................................................................................................................................... 184 Configuring the Calendar and Scheduling Processes ............................................................... 185 19.1 Working with Calendars ....................................................................................................................... 185 19.2 Scheduling Automated Processing .................................................................................................... 195 20 Updating the Correspondent Information File ............................................................................... 215 20.1 20.2 20.3 20.4 20.5 20.6 20.7 4 The Correspondent Information File .................................................................................................. 215 Running the Correspondent Information File Application ............................................................... 216 Displaying Records ............................................................................................................................... 216 Searching for Correspondents ............................................................................................................ 220 Correspondent File Window - Search Results ................................................................................. 225 Creating Correspondent Records ....................................................................................................... 226 Modifying Correspondent Records ..................................................................................................... 234 System Management Guide Table of Contents 20.8 20.9 20.10 20.11 20.12 21 Managing Message Partner Profiles .................................................................................................. 243 21.1 21.2 21.3 21.4 21.5 21.6 21.7 21.8 21.9 21.10 21.11 21.12 21.13 21.14 21.15 21.16 22 Displaying Exit Point Details ................................................................................................................ 302 Exit Point Window ................................................................................................................................. 302 Exit Point Details Window .................................................................................................................... 303 Defining an Exit Point ........................................................................................................................... 304 Modifying Exit Point Routing ............................................................................................................... 305 Removing an Exit Point Profile ........................................................................................................... 305 Configuring Queues ................................................................................................................................... 307 23.1 23.2 23.3 23.4 23.5 23.6 24 Application Interface ............................................................................................................................. 243 Message Partners and Message Partner Profiles ........................................................................... 243 Message Flow in the Application Interface ....................................................................................... 244 Connection Methods ............................................................................................................................. 245 Message Partner View ......................................................................................................................... 249 Status of Message Partner Sessions ................................................................................................. 251 Preparing the Application Interface for a Transfer Session ............................................................ 251 Creating a Message Partner Profile ................................................................................................... 252 Specifying the Connection Method ..................................................................................................... 253 Specifying the Emission Parameters ................................................................................................. 281 Specifying the Reception Parameters ............................................................................................... 285 Specifying Local Authentication .......................................................................................................... 291 Modifying a Message Partner Profile ................................................................................................. 296 Automatic Logical Terminal Allocation ............................................................................................... 297 Typical Configurations for Message Exchange Sessions ............................................................... 298 Configuration for Sanctions Screening over SWIFT ........................................................................ 300 Managing Exit Point Profiles ................................................................................................................. 302 22.1 22.2 22.3 22.4 22.5 22.6 23 Activating and Deactivating Correspondents .................................................................................... 235 Removing Correspondent Records .................................................................................................... 236 Managing Aliases .................................................................................................................................. 236 Managing Currency Records ............................................................................................................... 239 Managing Country Records ................................................................................................................. 241 Queues and Routing ............................................................................................................................. 307 Displaying Queues ................................................................................................................................ 307 Displaying Queue Details ..................................................................................................................... 308 Holding and Releasing Queues .......................................................................................................... 311 Modifying the Queue Threshold .......................................................................................................... 311 User-Defined Queues ........................................................................................................................... 311 Message Routing ........................................................................................................................................ 314 24.1 24.2 24.3 24.4 24.5 Message Routing Concept .................................................................................................................. 314 Routing Schemas .................................................................................................................................. 314 Routing Keywords ................................................................................................................................. 317 Routing Rules ........................................................................................................................................ 318 Using the Criteria Definition Window ................................................................................................. 328 15 July 2011 5 Alliance Access 7.0.20 24.6 Routing - Criteria Definition Window .................................................................................................. 328 24.7 List of Message Keywords ................................................................................................................... 331 24.8 Creating Simple Conditional Statements ........................................................................................... 342 25 Configuring Message Delivery (Delivery Subsets) ...................................................................... 344 25.1 25.2 25.3 25.4 25.5 25.6 26 Requesting a Report of Current Delivery Subsets ........................................................................... 344 Defining a Future Delivery Subset ...................................................................................................... 344 Example of Adding a Future Subset .................................................................................................. 354 Sending a Delivery Instructions Redefinition Request (MT 047) ................................................... 354 Synchronising Delivery Subsets ......................................................................................................... 355 Sharing Delivery Subsets ..................................................................................................................... 355 Import/Export of Message Templates ................................................................................................ 357 26.1 Import Message Templates ................................................................................................................. 357 26.2 Notes on Importing MT Templates ..................................................................................................... 358 26.3 Exporting Message Templates ........................................................................................................... 360 27 Increasing Message Throughput ......................................................................................................... 362 27.1 27.2 27.3 27.4 27.5 27.6 Message Throughput: A Definition ..................................................................................................... 362 Configuring Event Distribution ............................................................................................................. 362 Configuring the _SI_from_SWIFT Queue ......................................................................................... 363 Configuring the _SI_to_SWIFT Queue Threshold ........................................................................... 364 Configuring Two Logical Terminals for Input and Output ............................................................... 365 Configuring Three Message Partners ................................................................................................ 365 Part D – Appendices .......................................................................................................................................367 .Appendix A Default Profiles ...............................................................................................................................369 A.1 A.2 Standard Default Profiles ..................................................................................................................... 369 Printout of Default Routing Rules ....................................................................................................... 388 .Appendix B Default Settings ..............................................................................................................................389 B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 Types of Settings ................................................................................................................................... 389 Default Event Distribution .................................................................................................................... 390 Default Alarm Distribution .................................................................................................................... 390 Default Operator Profiles ..................................................................................................................... 390 Default Queue Visibility and Modification Rules ............................................................................... 391 Default Message Partner Profiles ....................................................................................................... 393 Default Security Configuration Parameters ....................................................................................... 393 Default System Configuration Parameters ........................................................................................ 393 .Appendix C Queues and Message Processing Functions ...................................................................394 C.1 C.2 C.3 C.4 List of System Queues ......................................................................................................................... 394 List of Exit Queues ................................................................................................................................ 403 Printout of Default Queues .................................................................................................................. 409 OI_to_OTHER Queue .......................................................................................................................... 410 .Appendix D Message Formats Used in AI ....................................................................................................411 D.1 6 PC Connect (DOS-PCC) ...................................................................................................................... 411 System Management Guide Table of Contents D.2 D.3 D.4 D.5 D.6 D.7 RJE .......................................................................................................................................................... 414 MERVA/2 Format .................................................................................................................................. 417 Common Application Server (CAS) Format ...................................................................................... 418 XML Formats ......................................................................................................................................... 425 MQ-MT Format ...................................................................................................................................... 534 Codes in the Trailer (Block S) ............................................................................................................. 538 .Appendix E Message Validation and Disposition .....................................................................................543 E.1 E.2 E.3 E.4 E.5 Message Validation and Disposition Overview ................................................................................ 543 Levels of Validation ............................................................................................................................... 544 Message Validation for RJE, DOS-PCC, and MERVA/2 Messages ............................................. 546 Message Validation for XML Messages ............................................................................................ 547 Message Validation for CAS Messages ............................................................................................ 548 .Appendix F Connection Methods in AI ..........................................................................................................553 F.1 F.2 F.3 F.4 F.5 F.6 Direct FileAct .......................................................................................................................................... 553 File Transfer ........................................................................................................................................... 564 Interactive ............................................................................................................................................... 573 Print ......................................................................................................................................................... 580 SOAP ...................................................................................................................................................... 587 WebSphere MQ ..................................................................................................................................... 616 .Appendix G Parameter Files in AI ....................................................................................................................633 G.1 G.2 G.3 Creating an Input Parameter File ....................................................................................................... 633 Authenticating Input Parameter Files ................................................................................................. 634 Specifying the Parameter File in the Message Partner Profile ...................................................... 635 .Appendix H Transmission and Delivery of FINCopy Messages .........................................................636 H.1 H.2 FINCopy Service ................................................................................................................................... 636 Failure Conditions ................................................................................................................................. 637 .Appendix I The FINCopy Server .......................................................................................................................638 I.1 I.2 I.3 Processing an Incoming MT 096 ........................................................................................................ 638 Processing an Outgoing MT 097 ........................................................................................................ 639 Re-authentication of Failed Messages .............................................................................................. 639 .Appendix J Handling Double-Authenticated Messages with FINCopy ...........................................643 J.1 J.2 J.3 Message Flow ........................................................................................................................................ 643 Implementation ...................................................................................................................................... 646 Examples of MT 096 and MT 097 with PKI Signatures .................................................................. 648 .Appendix K Command-line Tools ....................................................................................................................652 K.1 K.2 K.3 K.4 K.5 K.6 K.7 15 July 2011 getmesg .................................................................................................................................................. 652 messageTool ......................................................................................................................................... 654 reset_mp ................................................................................................................................................. 655 systeminfo (UNIX only) ......................................................................................................................... 656 saa_supportinfo ..................................................................................................................................... 656 saa_system integrity ............................................................................................................................. 659 saa_query ............................................................................................................................................... 660 7 Alliance Access 7.0.20 K.8 sa_split .................................................................................................................................................... 662 .Legal Notices .............................................................................................................................................................664 8 System Management Guide Preface Preface Purpose This System Management Guide describes how to set up, configure, and manage Alliance Access. Audience This guide presents information that is mandatory reading for Alliance Administrators or other personnel who are responsible for setting up and configuring the essential components of Alliance Access. This guide does not describe operations that must be carried out in terms of support. Such operations are described in detail in the Installation and Administration Guide. Staff who are responsible for day-to-day management of the Alliance Access system must refer to this guide regularly. 15 July 2011 9 Alliance Access 7.0.20 10 System Management Guide Part A - Introduction Part A Introduction 15 July 2011 11 Alliance Access 7.0.20 12 System Management Guide Understanding the Basics 1 Understanding the Basics Introduction This section describes how to sign on and sign off from Alliance Access, and introduces you to the Access Control application. 1.1 The Alliance Access Options Overview Alliance Access consists of applications that perform tasks related to the exchange of messages using the SWIFT network. You can access the Alliance Access graphical user interface by selecting either Alliance Workstation or Alliance Access from the Windows Start Programs menu. The Alliance Access option only appears if you are using Alliance Access at the server. The Alliance menu contains the following options: • Workstation runs the Access Control application which is the entry point to the rest of Alliance Access. • Installation groups applications that control the installation of Alliance Access. • Relicensing opens a program that enables you to license or relicense any additional packages and features that your institution can purchase from SWIFT. For more information, see "Relicensing" in the Installation and Administration Guide. This menu option only appears if you have installed the Alliance Access server. • System Administration groups applications that manage Alliance Access. This menu option only appears if you are using Alliance Access at the server. • Help opens the online help system. • Uninstall Alliance Access opens a window that enables you to remove Alliance Access. This menu option only appears if you have installed the Alliance Access server. • Uninstall Alliance Workstation opens a window that enables you to remove Alliance Workstation. This menu option only appears if you have installed Alliance Workstation. 1.2 Signing on to Alliance Access Overview To sign on to Alliance Access, you must know your Alliance Access operator name and password. Security Officers are responsible for providing you with this information. Note If you are running Alliance Workstation, then the Alliance Access server to which you want to connect must have an "active" instance configuration, set up using the Alliance Control application on your Alliance Workstation. The Alliance Access server must also be started. If this is not the case, then please consult your System Administrator. 15 July 2011 13 Alliance Access 7.0.20 Signing on for the first time Before you sign on to Alliance Access for the first time, you must obtain both your operator name and the two halves of your password from the Security Officers. The halves of the password consist of a left-hand and right-hand part. To complete the password, simply put both halves together. The password is always in uppercase. When you sign on for the first time, you are asked to change your password (see "Changing your Password" on page 22). Security Definition parameters determine the requirements for passwords (such as how long you can use the same password, and whether you can reuse passwords that you have used before). Your Alliance Access Security Officers configure these parameters. If you are not sure what the requirements are, then check with your Security Officers. One-time passwords Operators and Security Officers can also use One-time passwords (OTP) for the authentication (user name and password) of users. Operators can also be authenticated through LDAP repositories. To sign on to Alliance Access: 1. Log on to the operating system using your Windows user name and password. 2. Select Programs from the Windows Start menu. 3. Select Alliance Access. 4. Select the Workstation option from the sub-menu. The Sign-On screen appears. 5. Enter your Operator name and Password. The Alliance Access password is case sensitive, so make sure that you enter every character using the correct case. 6. If Active Instance Visible in Sign-On has been set in the Alliance Control application, then the Active Instance field appears. If this is the case, then the "active" instance configuration is shown. This is the Alliance Access server instance to which you connect. You can also select and activate a different Alliance Access server instance by selecting its instance configuration from the drop-down list in the Active Instance field. This feature is mainly for Alliance Workstation users so they can connect easily to different servers. Click 14 Sign On . System Management Guide Understanding the Basics Note 7. If your sign-on attempt to an Alliance Access instance fails for any reason, then the Active Instance field is not available because from this point on you are not allowed to change the active instance. If the problem when signing on was selecting the wrong instance, then you must quit this sign-on window and restart Alliance Workstation and re-select the instance. If your installation of the Alliance Access server has been configured to use user passwords, and this is the first time that you have logged on as this operator, then the Change Password dialog box prompts you to change the password. Enter your existing password in the Old Password field. 8. Enter a new password in the New Password field. The requirements for passwords (how long they must be, how long you can use the same password, and whether you can reuse passwords that you have used before) are configured on the Alliance Access server. If you are not sure what the requirements are, then check with your Alliance Security Officers. Remember your password and keep it a secret. Do not write it down. You can change your password at any time by selecting Change Password from the File menu in the Access Control window. 9. Enter the new password again in the Retype New Password field, and then click Note 1.3 OK . If you do not use Alliance Access for a certain length of time (the Signon Timeout period), then a dialog box appears. You cannot resume work with Alliance Access until you re-enter your password in the dialog box and click OK within a further period of time (the Signoff Timeout period). After the Signoff Timeout period has passed, you are signed off automatically. The System Administrator can change the Signon Timeout and Signoff Timeout period if necessary. The Access Control Window Overview When you sign on, the first window that you see is the Access Control window. The active instance that you are signed on to appears at the top of the window. Note The application icons that you see in the Access Control window may vary. The available applications depend on your operator profile. Overview of applications The following provides a brief description of each Alliance Access application: • The Application Interface application is used to import and export messages from and to other sources in your institution. 15 July 2011 15 Alliance Access 7.0.20 • The Calendar application is used to manage calendar(s). Within other Alliance Access applications, operators can use the calendar to schedule automatic operations. • The Correspondent Information File application allows you to update the Correspondent Information File (CIF) manually or by importing information from a SWIFT Alliance Bank File, which contains details of financial institutions. • The Event Journal application is used to search for events that occur in the system and help diagnose any problems. • The Message Approval application is used to verify and authorise SWIFT messages before they are sent. • The Message Creation application is used to create SWIFT FIN messages. • The Message File application is used to monitor the location and status of messages within Alliance Access. • The Message Modification application is used to modify SWIFT FIN messages to correct problems. • The Monitoring application is used to display continually updated information about all Alliance Access applications, servers, and message queues. • The Relationship Management application is used to authorise FIN messages. • The Routing application is used to define the rules controlling the flow of SWIFT messages through Alliance Access. • The Security Definition application is used to define operators on the system and configure various security parameters (such as password controls). • The SWIFT Interface application is used to connect you to the SWIFT network and send and receive SWIFT messages. • The SWIFT Support application provides general support for use of the Alliance Access interface to SWIFTNet FIN. • The SWIFTNet Interface application is used to create and manage emission and reception profiles for the transmission and the reception of InterAct and FileAct messages. • The SWIFTNet Support application is used to configure the SWIFTNet connections. • The System Management application is used to configure and administer your system. Modes of operation The mode in which Alliance Access is running can also affect the applications that are available to you. Alliance Access can run in either Operational Mode or Housekeeping Mode. Operational Mode is the normal multi-user mode for operating Alliance Access. Housekeeping mode is a maintenance mode. By default, only one user can sign on when Alliance Access is in Housekeeping mode. By default, only the Security Officers, Supervisors and the System Administrator can use the System Management application to stop Alliance Access and restart it in a different mode. Other operators can also be given this permission. Some applications and some functions within applications can only be used when Alliance Access is in a specific mode. Other applications and functions are available in both Operational 16 System Management Guide Understanding the Basics and Housekeeping mode. Where a specific mode is required to perform a task, this is indicated at the start of the task. The following applications are not available in Housekeeping mode: • Application Interface • Message Creation • Message Approval • Message Modification • Monitoring • Relationship Management • SWIFT Interface • SWIFTNet Interface • SWIFTNet Support. 1.4 The File Menu Overview You use the File menu in the Access Control window to control system settings, switch operators, or sign off. 1.4.1 Setting the Refresh Rate Overview Use the Set Refresh Rate command to set the rate at which system information, such as the contents of messages queues, is refreshed on your screen automatically. All screens which are refreshed automatically also have a manual refresh function which you can use to refresh the screen immediately. To set the refresh rate: 1. Select Set Refresh Rate from the File menu. The Refresh Rate dialog box appears: 2. Click in the Value field and type the duration, in seconds, that you want the data to be refreshed. The maximum refresh rate is 300 seconds. If you type 0 seconds, then the refresh option is turned off. 3. Click Note 15 July 2011 Modify to confirm your changes. You cannot use the Set Refresh Rate command to change the refresh rate if your speed mode setting is set to low speed. See "Setting the Speed Mode" on page 20 for details of how to set the speed mode setting. 17 Alliance Access 7.0.20 1.4.2 Setting Up the Printer Overview Use the Print Setup, Page Setup, and Printer Font commands to specify the printer that you want to use, the page settings and fonts to be used. Your printer setup: • applies to all Alliance Access applications except the Application Interface application, which has its own settings • applies only to you, and is associated with your Alliance Access operator name. Note If you install a new printer and set it up as the default printer within Windows while Alliance Access is running, then you can use the printer from any Alliance Access application. If you do not set the printer as the default, then you cannot access the printer until you have used the Alliance Access Print Setup command to specify the printer. To set up the printer: 1. If you do want to use the default printer, then select Print Setup... from the File menu. The Print Setup dialog box appears: 2. Select the Name of the printer that you want to use for printing. The Status, Type, Where and Comment fields display the printer information as defined by the Windows Print Manager. If you want to connect to a network printer, then click Network... and select the network printer from those displayed. If you want to change the properties of the printer, then click Properties and change the properties as required. 3. Click Note OK to save the printer settings. If you change the printer settings, then you must quit any applications that are already running and restart them before you can use the new settings within the applications. Specifying the page setup 1. 18 Select Page Setup... from the File menu. System Management Guide Understanding the Basics The Page Setup dialog box appears, showing the default page setup details: 2. Change the default page setup details as required. If necessary, select the Size and Source of the paper, specify the paper's Orientation, and enter the size of the margins. 3. Click Note OK to save the page settings. If you change the page settings, then you must quit any applications that are already running and restart them before you can use the new settings within the applications. Setting the printer font 1. Select Printer Font... from the File menu. . The Font dialog box appears: 2. Select the Font, Font style and Size of the printer font that you want to use. If necessary, select the available language script that is appropriate for the language that your computer is set up for. Note 15 July 2011 If you select a proportional font, then different columns of text in your printed outputs are not aligned properly. If you want text columns to be aligned, then select a non-proportional font such as Courier. 19 Alliance Access 7.0.20 3. Click Note 1.4.3 OK to save the font settings. If you change the font settings, then you must quit any applications that are already running and restart them before you can use the new settings within the applications. Setting the Speed Mode Overview Use the Low/High Speed Mode command to set the speed mode setting that your remote Alliance Workstation must use when connected to an Alliance Access server. To set the speed mode setting: 1. Select Low/High Speed Mode from the File menu. The Low speed mode settings dialog box appears. If you want your Alliance Workstation to use low speed mode when connected to an Alliance Access server, then select the Low Speed Mode option. This mode is recommended if you are using a low bandwidth line, such as a telephone line, as it reduces your Workstation's use of the line. In this mode: • the number of records retrieved each time that a list of objects appears, is reduced to 50, as shown in the Size of pages field • the Automatic refresh is enabled box is blank, showing that your screen display is not refreshed automatically for most Alliance Access applications, except when a new object is added. In the message preparation applications, lists of internal correspondents or aliases are no longer provided. In the Application Interface application, the details for a message partner are refreshed if you click the message partner list. Similarly, in the SWIFT Interface application, Logical Terminal details are refreshed if you click the list. For details of the Sort allowed on partial lists and Main lists have a grid aspect check boxes, see steps 3 and 4. Note 2. 20 If you select the Low Speed Mode option, then you can no longer use the Set Refresh Rate command from the File menu to change the refresh rate. If you want your Alliance Workstation to use high speed mode when connected to an Alliance Access server, then select the High Speed Mode option. System Management Guide Understanding the Basics This mode is recommended if you are using a high bandwidth line, such as a LAN line. In this mode: • the number of records retrieved each time that a list of objects appears, is increased to 1024, as shown in the Size of pages field • the Automatic refresh is enabled box is checked, showing that your screen display is refreshed automatically whenever any change occurs to the objects shown. 3. When a list of items appears in a window, you can sort the items by clicking a column heading (for details, see "Sorting Items" on page 32). Alliance Access sorts a list completely only if the number of items in the list are equal to or less than 1024 (or 50 in Low Speed Mode). You can specify how Alliance Access sorts lists of more than 1024 items (or more than 50 items in Low Speed Mode), by using the Sort allowed on partial list check box: • if the box is checked, when you click a column heading, then Alliance Access sorts the 1024 items that are currently active (or 50 items in Low Speed Mode), so the list is only partially sorted. If you display the next "page" of items, then these are correctly sorted, and so on. Effectively, the list is sorted into separately sorted sets of 1024 items (or 50 items). • if the box is not checked, when you click a column heading, then Alliance Access does not sort the list at all. 4. 15 July 2011 If you want items listed in any window to appear within a grid, then check Main lists have a grid aspect. 21 Alliance Access 7.0.20 1.4.4 Changing your Password Overview Use the Change Password command to change your password at any time. You are recommended to change your password frequently to guarantee system security. This command is not available if your operator definition is set to use One-Time or LDAP passwords. Note The same applies to the left security officer and right security officer if the Password: Sec Officer One Time Pwd security parameter is set to Yes. When you are changing your password, you must remember that good passwords: • contain a mixture of both lower-case and upper-case characters • contain numbers as well as letters • do not consist of the same characters repeated two or more times, for example, do not use swiftswift as a password. To change your password: 1. Select Change Password from the File menu. The Change Password dialog box appears. a. Type your existing password in the Old Password field. b. Type a new password in the New Password field. You must remember your password and keep it a secret. Do not write it down. c. Type the new password again in the Retype New Password field. This is to ensure that you did not make an error when typing in the new password. 2. 1.4.5 Click OK . Signing Off from Alliance Access Overview Use the Sign off command to quit the Access Control window. Signing off prevents unauthorised access and frees resources for other processes on your computer and on the server. 22 System Management Guide Understanding the Basics To sign off from Alliance Access: 1. Select Sign off from the File menu. If there are no applications running, then Alliance Access asks you to confirm your request. If any applications are open, then an Application Exit dialog box appears. Confirming a sign-off forces an orderly close of the applications. If any applications are open, then the dialog box warns you that any unsaved data will be lost. 2. 15 July 2011 Click OK to confirm or Cancel to abort the sign-off process. If you confirm the sign-off, then Alliance Access returns you to the operating system. 23 Alliance Access 7.0.20 2 Using Applications Introduction This section gives a general overview about how to use the Alliance applications. It also introduces some Alliance terms that are used frequently in the other Alliance guides. 2.1 Running Applications Overview After you sign on as described in "Signing on to Alliance Access" on page 13, the Access Control window displays icons for the applications that you have permission to use. There are several ways of running an application from the Access Control window: • double-click the application icon • click an application icon and press Ctrl + O or Enter • click an application icon and select Open from the Application menu (if you are not sure how to select menus, see "Selecting Commands" on page 24). You can set different default applications to run when Alliance is in Operational mode and Housekeeping mode. All applications operate in a similar way in terms of their windows, menus, and commands. 2.1.1 Selecting Commands Overview The names of the menus that you can use are always displayed on a menu bar near the top of an application window, beneath the name of the window itself. To select a command from the menu bar in any application: 2.1.2 1. Click the menu name. The menu opens, showing a list of the commands that are available. 2. Click the command name. Alliance attempts to perform the command. Using Commands Overview Many menu commands perform an action on an item. To use these commands, you must select an item first and then select the menu command. For example, you can run an application from the Access Control window. To use a command: 24 1. Click an application icon. 2. Click Application near the top of the Access Control window, to select the Application menu. A list of the commands in the menu appears. 3. Click Open from the Application menu. The application opens and starts running. System Management Guide Using Applications 2.1.3 Running Applications Automatically Overview You can select an application to run automatically each time that you sign on. To select an application to run automatically: 2.1.4 1. Click the icon for the application that you want to run after you sign on. 2. Select Set As Default Application from the Application menu. Windows and Dialog Boxes Overview When you run an Alliance application, the first window that appears usually shows a list of the items managed by that application. For example, the Message File application main window shows a list of messages: When you open certain applications, a search dialog box appears first. For example, when you run the Event Journal application, the Event Journal search dialog box appears, with the search criteria fields organised over three different tabs. 15 July 2011 25 Alliance Access 7.0.20 After you enter details of the events you want to search for, Alliance searches for these events and displays them within the main Event Journal window. In some cases, there is more information than can be comfortably fitted into a window. In these cases, you can use the View menu to select which details appear. In many applications, you can double-click an item to see more details about it. The details are displayed in a dialog box divided into tabs. The dialog box opens in the centre of the window. You may want to rearrange the display so that the dialog box, toolbar, and menus are all visible at once. You can also re-size or maximise the main window and save the new size as a setting using the File/Save Current Setting command. 2.1.5 Status Bars Overview Most applications have a status bar and toolbar. As well as the usual indications of whether Caps Lock, Scroll Lock, and Num Lock are on or off, the status bar is used to display information about the current context. For example, if you select an option from a menu, the status bar displays a brief description of what that option does. The current speed mode setting is also shown in the status bar. Certain applications also give additional information. In the Message Details dialog box of the Message Creation application, for example, if you are entering or editing a field in the message header or in prompted mode, the status bar displays a description of the required syntax of the current field as well as the current and maximum allowed size of the message. To display or hide a status bar, select the Status Bar command from the Options menu. 2.1.6 Toolbars Overview The toolbar gives direct access to the most commonly used actions within the application. The Message Details toolbar in the Message Creation application, for example, has functions such as disposing, routing, printing, switching between the header and text views, and so on. 26 System Management Guide Using Applications If you are not sure what a particular button on a toolbar does, then position the mouse pointer over the button. A short description appears below the button. To display or hide a toolbar, select Toolbar from the Options menu. This toggles the toolbar on or off. 2.1.7 Keyboard Shortcuts Overview Many commands have shortcut keys which are listed next to them on the menus. Keys that must be pressed at the same time are separated by a plus sign. Mnemonics A mnemonic is a single character associated with a menu, or with a command within a menu. When a menu or command has a mnemonic, the mnemonic appears as an underlined character: • If a menu has a mnemonic, then you can open the menu by pressing the meta key and the mnemonic character simultaneously. The meta key is a key such as Alt, as defined by your System Administrator. If you are not sure what the meta key is on your system, then check with your System Administrator. • If a command within an open menu has a mnemonic, then you can activate the command simply by pressing the mnemonic character. Note Mnemonics are case sensitive. Accelerators An accelerator is a combination of keys which appear next to a command on a menu. You can activate the command without displaying the menu which contains the command by pressing the accelerator keys simultaneously. For example, in the Access Control window, the Sign off command on the File menu has the accelerator Ctrl-S, so you can activate the command by holding down the Ctrl key and pressing S. 2.2 Standard Menus Overview Some menus are available in many of the Alliance applications. The following sections describe how to use the commands in these menus. 2.2.1 File Menu Overview Use the following commands on the File menu to save the current settings, refresh the screen, or quit an application: 15 July 2011 Use To Save Current Settings Save settings and preferences. They become the default settings and preferences for the application. The positions of any windows that are open at the moment the Save Current Settings command is run are saved. If you have rearranged the order of the information within a column (see "Sorting 27 Alliance Access 7.0.20 Use To Items" on page 32), or the columns in a list (see "Rearranging Columns" on page 33), then the changed column information or column order is saved. 2.2.2 Refresh Now Refresh a screen with the latest data. Exit Quit the application. Edit Menu Overview Use the commands on the Edit menu of a main window to copy or select items in a list. Use To Copy Copy selected lines from a list into the clipboard. Select All Select all items in a list. Deselect All Deselect all items in a list. You can also select a single item by clicking it. The item becomes highlighted. You can deselect the item by holding down the Ctrl key and clicking again on the item. In some lists, you can select more than one item by holding down Ctrl and clicking each required item. 2.2.3 View Menu Overview Use the View menu to select which list panes appear within a main window. 2.2.4 Help Menu Overview Use the commands on the Help menu to access the online help system or to display information about your working environment. Use To Help Topics Display the contents of the Help system. From here, you can access search for help on specific topics. About... Display information about the application you are using. If you have a problem with your system, then you may be asked to provide details of your system to help diagnose the difficulty. Selecting the About option on the Help menu displays useful information about your system, such as the type of server that you are using, and the current server mode. 28 System Management Guide Using Applications 2.3 Shortcut Menus Overview To display a shortcut menu of the most frequently used commands for an application, click the right mouse button while using the application. The commands on a shortcut menu vary depending on the application and the action that you are performing. For example, if you run the Message File application, select a message, and then click the right mouse button, the shortcut menu appears. If the message is opened, then clicking the right mouse button displays a different shortcut menu. 15 July 2011 29 Alliance Access 7.0.20 You select commands from a shortcut menu in the same way that you select commands from a standard menu. 2.4 Printing Reports Overview Many applications have a Print command which you use to obtain a printed report listing items or item details. If you select Print from a main window which contains a list of items, then the displayed list is printed. If you select some items in a list before selecting the Print command, then you can select to print either all items in the list, or the selected items only. If you select Print from a window in which the details of a single item appear (for example, the details of a message), then the details are printed. To print a report: 30 1. Run the application. 2. Search for the items you want a report on (if they do not already appear). Searching for items is described for each application later on in this guide. 3. If you want to print several items in a list, then select them. 4. Select Print from the menu named after the item (for example, the Event menu or the Message menu). The Print Report dialog box appears. System Management Guide Using Applications 5. Click Items All to print all the items in a list or Selected to print only selected items. Click Details All to print all the details for the items or None to print only the details shown in the window. 6. Check Print Preview if you want to see the report before you print it out. You can use the following buttons within the Print Preview window: 2.5 • Print • Next Page shows the next page of the report • Prev. Page shows the previous page of the report • Two Page • Zoom In • Zoom Out • Close prints the report out shows two pages side by side shows an enlarged view of the report shows a reduced view of the report quits the Print Preview window without printing the report. 7. If you want to print to a file, then check Print to File and enter the File name, or browse for an existing file (which will be overwritten). The report file is printed to the Report subdirectory, which is within the directory where Alliance Access is installed on your machine. 8. Click OK . Printing Messages Overview The message preparation applications (Message Creation, Message Approval, and Message Modification) can be used to print copies of messages. A print preview allows you to review a message before sending it to a printer. You can also configure the number of messages to be printed. A printer must be configured through a message partner profile with the connection method of type Print. For more information about how to configure a Print message partner, see the System Management Guide. 15 July 2011 31 Alliance Access 7.0.20 2.6 Entering Dates and Times Overview When using an Alliance application, you may need to enter a date and time. Your System Administrator uses the System Management application to specify the format used for dates and times on your system. When entering dates or times, one shortcut that you can use is to specify an offset value: a value preceded by a plus or minus sign. The result is the current date or time, plus or minus the specified offset. Entering -2 as the date on 5 February, for example, goes back to 3 February. In addition, you can also specify an offset for a specific part of the date, or time by specifying the offset unit: • for dates: D for days, M for months, and Y for years. -2D goes back two days, -2M goes back two months, -2Y goes back two years from the current date • for times: H for hours, M for minutes, and S for seconds. -2H goes back 2 hours, -2M goes back 2 minutes, -2S goes back 2 seconds from the current time. 2.7 Sorting Items Overview When a list of items appears within a window, you can sort and save them into order using any of the column headings. For example, you can display a list of events in the Event Journal main window, sorted in Date & Time order, from most recent date and time to oldest date and time. To sort items into a different column order, click the title of any column. The items are sorted into descending order (this is shown by appearing next to Date & Time in the example above). Clicking the same column title a second time sorts the items into ascending order. This is shown by appearing next to the heading. For example, clicking Operator sorts the events into descending alphabetical order of operator name. Clicking Operator a second time sorts the events into ascending alphabetical order of operator name. 32 System Management Guide Using Applications Normally, when you click a column heading, Alliance sorts a list completely if there are 1024 items or less. This is because Alliance retrieves records in 'pages' of 1024 items. If the Low Speed Mode option is set (see "Setting the Speed Mode" on page 20), then the page size is set to 50, so Alliance sorts a list completely only if there are 50 items or less. If there are more than 1024 items (or 50 items, in low speed mode), then Alliance sorts the items according to the Sort allowed on partial list setting in the Low Speed Mode Settings dialog box (see "Setting the Speed Mode Setting" step 3). Depending on this setting, you can either sort a long list only partially by clicking a column heading, or you may not be able to sort the list at all. For this reason, when you are searching for items, always refine your search criteria carefully so that the number of items meeting the criteria is as small as possible. Note In some applications (for example, the Message File application), you can use a menu option to sort a list. Menu options sort a list completely, regardless of the number of items in the list. However, if you use a sort menu option initially and then sort the same list by clicking a column heading, the sort is subject to the restrictions described above. To avoid confusion when sorting long lists of items, you may prefer to use only one sorting method within an application. Alliance allows each operator to save their sorting information settings for each individual application. Select Save Current Settings from the File menu after all the changes have been completed. 2.8 Rearranging Columns Overview When a list of items appears within a window, you can rearrange and save the order of the columns in the list. For example, suppose you have sorted a list of events in the Event Journal main window in order of operator name. 15 July 2011 33 Alliance Access 7.0.20 You would like the Operator column to be the first column on the left in the window. To move any column to a new position: 1. Click the column heading, and continue to hold the mouse button down. 2. Drag the column heading to its new position. You must drag the column heading completely past the column heading already at the new position. 3. Release the mouse button. The Operator column is now the first column in the window. 4. 34 Select Save Current Settings from the File menu to save the new position of the column. System Management Guide Using Applications 2.9 Selecting a File Overview In some applications, you can specify the file name and the path to it. You can enter the path and file name directly, or use a file browser to identify the file. For example, in the SWIFT Support application, you can use the Import Message Templates command to import templates from a file that was previously exported. The Import Message Templates dialog box includes a Template File field where you either enter the path of a template file directly, or click the browse button ( ... ) to locate it. Clicking the browse button opens the file browser, which you can use to navigate through directories, view files and sub-directories within them, and select the required file. 15 July 2011 35 Alliance Access 7.0.20 Some commands enable you to specify whether a file is located on the Workstation or on the server. 36 System Management Guide Part B - Housekeeping Tasks Part B Housekeeping Tasks 15 July 2011 37 Alliance Access 7.0.20 38 System Management Guide Installing the SWIFT Alliance Bank File 3 Installing the SWIFT Alliance Bank File Overview SWIFT distributes a new Alliance Bank File regularly. SWIFT recommends that you install it, to keep your Correspondent Information File (CIF) synchronised with the latest publication. 3.1 Alliance Bank Files Alliance Bank Files The Alliance Bank File contains the BIC information of all the institutions that currently use the SWIFT network either directly or through another party. The file contents are like the printed version of the BIC Directory except that the data is provided in a different layout and in different character sets. The Message preparation, Application Interface, and Relationship Management applications use the information in this file to display BICs in expanded format. Note The Alliance Bank File is sometimes referred to as the BIC file. Updates to an Alliance Bank File The Alliance Bank File which contains information for all institutions is a Full Bank File. Between each distribution of a Full Bank File, SWIFT also distributes a delta file. This delta file contains only the changes since the last Full Bank File was issued. It only contains entries that have been added, modified, or deleted. In this document, this file is called a Bank Update File. 3.2 Options for Installing an Alliance Bank File Overview Periodically, SWIFT distributes a new Alliance Bank File on the BIC Portal at www.swift.com. SWIFT recommends that you install the Alliance Bank File on a regular basis, to keep your Correspondent Information File (CIF) synchronised with the latest publication. This section outlines the options available for installing a Full Bank File or Bank Update File: • "Install immediately in housekeeping mode" • "Install automatically" • "Schedule the installation of a Bank Update File" • "Bank Update File installation in operational mode" Important During the installation of Alliance Access, you must install a Full Bank File. Install immediately in housekeeping mode Installing a Bank File immediately involves the following tasks: 1. Download the Full Bank File or the Bank Update File to the BIC file directory. For more information, see "Download an Alliance Bank File" on page 42. 15 July 2011 39 Alliance Access 7.0.20 Note 2. An Alliance Workstation started from an Alliance Access server installed on Windows, provides the command Load BIC Files. This command downloads the Full Bank File to the BIC file directory or the Bank Update File to the UpdateBIC file directory. For more information, see "Loading the Bank Files from Disk" on page 44. Install the Bank File while the server is running in Housekeeping mode. Install automatically Installing a Full Bank File automatically involves the following tasks: 1. Download the Full Bank File to the BIC file directory. For more information, see "Download an Alliance Bank File" on page 42. Note 2. A Workstation started from an Alliance Access server installed on Windows, provides the command Load BIC Files. This command downloads the Full Bank File to the BIC file directory or the Bank Update File to the UpdateBIC file directory. For more information, see "Loading the Bank Files from Disk" on page 44. The bank file installs automatically at the next restart of the Alliance Access server. Each time the Alliance Access servers are stopped, the system checks whether a Full Bank File is present in the BIC file directory. If a file is present, then Alliance Access installs it after the servers have been stopped and before the next restart. After successful activation of the Bank File in the Alliance Access database, the file is deleted from the BIC file directory. After this activation, or in case of a failure, an event is recorded in the Event Journal the next time that the Alliance Access starts. Schedule the installation of a Bank Update File Scheduling the installation of a Bank Update File involves the following tasks: 1. Create a schedule for the installation of the Bank Update File. 2. The installation of the Bank File will take place when the scheduled action is executed. If an update file is available in the UpdateBIC directory, then the file is installed at the scheduled time. You do not have to restart the servers after the file is installed. After successful activation of the Alliance Bank File in the Alliance Access database, the file is deleted from the UpdateBIC file directory. After this activation, or in case of a failure, an event is recorded in the Event Journal. Bank Update File installation in operational mode Installing the Update File in operational mode involves the following tasks: 1. Download the Bank Update File to the UpdateBIC directory. Note 2. 40 A Workstation started from an Alliance Access server installed on Windows, provides the command Load BIC Files. This command downloads the Bank Update File to the UpdateBIC file directory. For more information, see "Loading the Bank Files from Disk". Load the Bank Update File while the server is running in operational mode. System Management Guide Installing the SWIFT Alliance Bank File After successful activation of the Bank File in the Alliance Access database, the file is deleted from the UpdateBIC file directory. 3.3 What Happens During Bank File Installation Update on BIC Load The Correspondent Information File (CIF) contains correspondent, country, and currency records, plus details of the aliases (alternative names) for correspondents. Each correspondent, country, and currency record has an Update on BIC Load field, which can be set to Yes or No. When you install a Bank File (Full or Update file) 1. New record Alliance Access adds new records in the Bank File to the CIF automatically. 2. Update of a record If an existing correspondent record in the CIF has the Update on BIC Load field set to Yes, and some information has changed (for example, a correspondent has a new address), then the correspondent record is updated with the changes. 3. Deletion of a record If the Bank File shows that a correspondent record must be deleted or if the correspondent does not appear in the Bank File, then Alliance Access checks the record and the following occurs: • If at least one defined application is selected, then the correspondent record is not deleted. An event is recorded in a journal explaining why the correspondent was not deleted. • If no defined application is selected, then Alliance Access checks the preferred network applications used within the correspondent: – If SWIFT is the only Preferred Network application, then the correspondent record is deleted, and details of the correspondent are removed from any alias record automatically. – If SWIFT is not the only Preferred Network application, then the record is not deleted. Alliance Access removes SWIFT from the list of Preferred Network applications for the correspondent and creates an entry in the Event Journal. This entry informs you that it was not possible to remove the correspondent automatically, and lists the defined applications for the correspondent. Note Even if an existing correspondent record in the CIF has the Update on BIC Load field set to No, SWIFT is removed from the list of Preferred Network Applications. • If the SWIFTNet Interface is present, then SWIFTNet is also added as the preferred network to all correspondents, except for internal correspondents and the BIC1 correspondents. 15 July 2011 41 Alliance Access 7.0.20 Note 3.4 The Status of existing correspondent records remains unchanged when you install a new Bank File, whether the Update on BIC Load field is set to Yes or No. Therefore, if a record was made Inactive, it will still be Inactive after installing the new Bank File. Download an Alliance Bank File Purpose You can download the Alliance Bank File in several data formats from the BIC Portal on www.swift.com. To download a Bank File on UNIX: 1. Log on as an Alliance Administrator (all_adm). The System Administration window appears. 2. Open an X-term from the OS Configuration menu in the System Administration window. 3. Create a temporary directory on the Alliance Access server, to which the all_adm user has access. For example, /tmp. 4. Download the Bank File from the BIC Portal page on www.swift.com. The file is packaged in .tar.Z format. 5. Change to the installation directory for the Full Bank File or Bank Update File, as follows: • For a Full Bank File: cd $ALLIANCE/data/BIC • For a Bank Update File: cd $ALLIANCE/data/UpdateBIC Where $ALLIANCE is the installation directory of Alliance Access. Installing Alliance Access creates these directories automatically. 6. Copy and uncompress the Full Bank file or Bank Update File from the temporary directory to the installation directory for the Bank File, as follows: cp /tmp/<file> . uncompress <file> Where <file> is the name of the file, as follows: • Full Bank File - ALLIANCEBANK_UNIX_FULL_20071103_TXT[1].tar.Z • Bank update File - ALLIANCEBANK_UNIX_DELTA_20071103_TXT[1].tar.Z 7. Extract the Bank File, as follows: tar xvf <file> Where <file> is the name of the file, with a .tar extension. The contents of the Bank File is extracted to the current directory. 8. Remove the .tar file, as follows: rm <file> 42 System Management Guide Installing the SWIFT Alliance Bank File Where <file> is the name of the file, with a .tar extension. To download a Bank File on Windows: 1. Create a temporary directory on the Alliance Access server, to which the Alliance Administrator user has access. For example, \temp. 2. Download the Bank File from the BIC Portal on www.swift.com. The file is packaged in .ZIP format. 3. Choose one of the following: • Unzip the contents of the file to the installation directory for the Full Bank File or Bank Update File. • Unzip the contents of the file to a temporary folder and use the Load BIC Files command as explained in "Loading the Bank Files from Disk". 3.5 Install an Alliance Bank File Immediately Purpose This section describes how to install an Alliance Bank File (Full or Update) immediately after downloading it. This process requires that the Alliance Access server is running in housekeeping mode. Installing a Bank Update File You can also install a Bank Update File while the server is running in Operational Mode. In that case, do not perform step 7 of this procedure. Permissions for installing the Bank File An operator with the R7.0_Supervisor profile, or an operator who has been given this permission, can install the Bank File. The left security officer or right security officer cannot perform this task. Before you begin Download the SWIFT Alliance Bank File. For more information, see "Download an Alliance Bank File" on page 42. To install a Full Bank file immediately: 15 July 2011 1. Sign on to Alliance Access. 2. Double-click the Correspondent Info icon in the Access Control window. 3. Select Update from BIC from the File menu. 43 Alliance Access 7.0.20 4. Select Full BIC file or BIC update file. If you select BIC update file, then Update Operating Mode is set to Manual. 5. Select the location of the Bank File. The file must be located in the following directory: File type 6. Full Bank File $ALLIANCE\data\BIC Bank Update File $ALLIANCE\data\UpdateBIC Click Continue Important 7. Required location . A message confirms that the file is being loaded. Do not stop the Alliance Access servers until the installation of the Bank File is completed. Restart the servers in operational mode. When the installation of a Bank File is completed, Alliance Access: • records an event about it in the Event Journal • removes the Bank File from the installation directory. 3.6 Loading the Bank Files from Disk Purpose On Windows, you can load the Bank Files from disk when you are using local Alliance Workstation, that is, a workstation that runs on the same machine as an Alliance Access server. To load the Bank File from disk: 44 1. Sign on to Alliance Access. 2. Double-click the Correspondent Info icon in the Access Control window. 3. Select Load BIC Files... from the File menu. The Load BIC Files window appears. 4. Select Full BIC file or BIC update file, as appropriate. System Management Guide Installing the SWIFT Alliance Bank File 5. In the File location field, use the browse button ( 6. Click Note 7. OK and then Continue ... ) to locate the files. . Before copying the Bank File information, the system verifies that there is sufficient space in the Alliance database. If sufficient disk space is not available, then an error message appears. When a confirmation message appears, click OK . The file is copied to one of the following directories: • Full Bank File: <Alliance Installation Directory>\data\BIC • Bank Update File: <Alliance Installation Directory>\data\UpdateBIC 15 July 2011 45 Alliance Access 7.0.20 4 Installing Message Syntax Tables Introduction This section contains instructions for installing and assigning Message Syntax Tables using the SWIFT Support application. Note 4.1 To perform the tasks described in this section, the Alliance Access servers must be restarted in Housekeeping mode. Message Syntax Tables Overview Correspondents on the SWIFT network can understand each other's messages because the syntax used in the messages is standardised. When a message is sent or received by a logical terminal, its syntax is checked automatically. The logical terminal can do this check because it has a message syntax table assigned to it which describes the syntax that is used in all the message types sent through the SWIFT network. The system compares the contents of the message with what the message syntax table states must be there and informs you of any inconsistencies. The message syntax table contains details of the: • message types that can be sent and received • length and type of character strings in fields • character sets • field expansion. SWIFT releases a new message syntax table version every year, that must be installed and assigned to the logical terminals on Alliance Access. 4.1.1 Installing a Message Syntax Table Prerequisite To install the message syntax table, the message syntax table data must have already been downloaded into the system. The message syntax table valid at the time of the software release is automatically loaded during the installation of Alliance Access. A new release of message syntax tables contains clear instructions in the related Release Letter. To install a message syntax table: 46 1. Start the Alliance Access servers in Housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Mstv Id. The Message Table window appears, displaying the list of installed message syntax tables. System Management Guide Installing Message Syntax Tables 4. From the Mstv Id menu, select Install. The Message Syntax Tables dialog box appears. 5. From the Version field, select the message syntax table version. 6. Every message within Alliance Access has a unique message identifier (UMID) that is created from information in its header and its text. The unique message identifiers in Alliance Access are built from either the Transaction Reference Number or the Message User Reference of the related message. In the Build Message Identifier (UMID) on field, select either TRN or MUR. 7. Click Note 4.2 Install to install the table. If you are running Alliance Access in Low Speed Mode, then you must singleclick the Message Syntax Table window, or press F5 to refresh it. Setting a Default Message Syntax Table Introduction When you have multiple Message Syntax Tables installed, you can set which are used by default for the validation of Live or Test & Training input messages with sender Logical Terminal code X. For more information, see "Automatic Logical Terminal Allocation" on page 297. Setting a default Message Syntax Table can only be done in Housekeeping mode. To set a default Message Syntax Table: 15 July 2011 1. Start the Alliance Access servers in Housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Mstv Id. The Message Table window appears, displaying the list of installed message syntax tables. 4. Select the Message Syntax table you wish to set as the default. 47 Alliance Access 7.0.20 5. 48 From the Mstv Id menu, select Set Default Live or Set Default T&T as appropriate. System Management Guide Creating and Configuring Your Logical Terminals 5 Creating and Configuring Your Logical Terminals Introduction This section contains instructions for: • creating logical terminals using the SWIFT Support application • configuring logical terminals using the SWIFT Support and SWIFT Interface applications • enabling automatic logical terminal allocation using the System Management application, which provides a way to balance the load of queued messages across available logical terminals. The destinations that your institution is licensed to use are created during installation. Each logical terminal is identified by a destination and a terminal code. When you first install Alliance Access or when you purchase additional logical terminals, they must be defined using the SWIFT Support application. There are two types of logical terminals: • Live • FIN test and training. Note 5.1 To create logical terminals, the servers must be running in Housekeeping mode. Creating Logical Terminals To create a logical terminal: 15 July 2011 1. Start the Alliance Access servers in Housekeeping mode. 2. Start an Alliance Workstation. 3. Run the SWIFT Support application. 4. From the View menu, select Logical Terminal. The Logical Terminal window appears, displaying the list of defined logical terminals. 5. Create a logical terminal by selecting New from the Logical Terminal menu, or based on an existing one by selecting a logical terminal and then selecting New As from the Logical Terminal menu. The Logical Terminal Details window appears. 49 Alliance Access 7.0.20 6. In the Destination field, select a destination. All the destinations that your institution is licensed for are listed. 7. In the TC field, type a terminal code. This can be any alphanumeric character except 0, 1 or X. If you enter a terminal code that has already been assigned to a destination, then an error message appears. 8. Select a message syntax table from the MSTV Id field. 9. In the Window Size field, specify, for the logical terminal you are creating, the value of the requested window size when a FIN session is opened. This value is used when a FIN session is opened. The window size determines how many messages can be sent to the network without having to wait for an acknowledgement from FIN. Enter a value between 1 and 99, the default is 10. The value in this field can be changed if necessary, by repeating this step. Note This value must match the FIN window size requested to SWIFT for the logical terminal. 10. In the Master BIC for T&T field (for Test and Training logical terminals only), select the Master BIC (BIC8) from which Alliance Gateway determines which Authoriser DN to use when you log in with your Test and Training logical terminal. 11. From the Logical Terminal menu, select Add. The list is updated. Note If you are running Alliance Access in Low Speed Mode, then you must singleclick the Logical Terminal window or press F5 to refresh it (Windows servers only). You cannot remove a logical terminal once it is created. It remains in the system as long as the destination is licensed. 5.2 Assigning a Message Syntax Table Overview A logical terminal must have a message syntax table assigned to it, so that it can validate the messages it sends and receives. When a new message syntax table becomes available, you can assign it to a logical terminal. Note 50 Do not assign a new Message Syntax Table to a live logical terminal before it actually becomes live on the network. System Management Guide Creating and Configuring Your Logical Terminals To assign a message syntax table: 5.3 1. Start the Alliance Access servers in Housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Logical Terminal. 4. Double-click the logical terminal that you want to assign a table to. The Logical Terminal Details dialog box appears. 5. In the MSTV Id field, select a new table from the list. 6. From the Logical Terminal menu, select Modify. Selecting the Window Size Overview This section describes how to select the window size for your logical terminal. To select the window size: 1. Start the Alliance Access servers in Housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Logical Terminal. 4. Double-click the logical terminal for which you want to select a window size. The Logical Terminal Details dialog box appears. 5. In the Window Size field, specify the value of the requested window size when a FIN session is opened. This value is used when a FIN session is opened. The window size determines how many messages can be sent to the network without having to wait for an acknowledgement from FIN.Enter a value between 1 and 99, the default being 10. The value in this field can be changed if necessary, by repeating this step. 15 July 2011 51 Alliance Access 7.0.20 Note 6. 5.4 This value must match the FIN window size requested to SWIFT for the logical terminal. From the Logical Terminal menu, select Modify. Automatic Logical Terminal Allocation Overview Automatic logical terminal allocation provides a way to balance the load of queued messages for a given destination across available logical terminals, rather than using a specific sender logical terminal normally defined in each message. 5.4.1 Limitations Overview In using automatic logical terminal allocation, the following limitations apply: • Automatic logical terminal allocation is disabled for any destination that does have at least one logical terminal not having a designated connection. • Logical terminals used for automatic logical terminal allocation must use the same message syntax table. This is verified each time the SIS component is started. • All logical terminals of a given destination must have the same protocol version. This is assumed, it is not validated by the software. • During an interrupt, the messages handled by a logical terminal that have not received an acknowledgement from the network are reserved until the logical terminal is reconnected. Reserved messages can be released using the Abort command on the logical terminal. The messages are returned to the message pool and transmitted by the next logical terminal allocated by the system. Note 5.4.2 If you are using a back-office application, then read the considerations described in "Automatic Logical Terminal Allocation" on page 297 before using automatic logical terminal allocation. Enabling Automatic Logical Terminal Allocation To enable automatic logical terminal allocation: 52 1. Run the System Management application. 2. If the configuration parameters are not shown, then select Configuration from the View menu. 3. In the Configuration - System Management window, double-click the item relating to logical terminal load balancing or select it and select Open from the Configuration menu. The LT load balancing window appears. System Management Guide Creating and Configuring Your Logical Terminals 15 July 2011 4. Select On for the Value field. 5. Select Modify from the Configuration menu to save the change. 6. Restart the SWIFT Interface Services component if required (that is, if you are in operational mode), as described in "Stopping and Restarting Components" on page 74. If you are in Housekeeping mode, then the change takes effect at the next restart in operational mode. 53 Alliance Access 7.0.20 6 Managing the MX Message Standards Introduction SWIFT distributes the standards for XML messages using message standards deployment packages. You are provided with a "Digest" for these Message Standards. You have to use this when installing the Message Standards to ensure that you are installing valid standards. The MX Message Standards are managed from the functionality available in the SWIFT Support application. You can view the standards installed, install new standards, or remove redundant standards. To install or remove an MX Message Standard, the Alliance Access servers must be running in housekeeping mode. 6.1 Viewing and Printing MX Message Standards To view and print the installed MX Message Standards: 1. Run the SWIFT Support application. 2. From the View menu, select Message Standards. The Message Standards main window appears. For each message standard, the following information appears: • Name • Service Name • Description • Creation date. To print the information, select the message standard and click Print. 3. In the Print dialog box that appears, select the required options and click OK . For each message contained in the selected standard, the following information is printed when Print All details is selected in the Print dialog box: • Message name • Identifier, the message identifier (for example, ifds.001.001.01) • Description • Syntax version (for example, 01) • Patch number: this is the number of a patch that contained a correction for this message definition (equal to 0 if no correction was issued on this message) • Delivery mode (the value is extracted from the corresponding MX Message Standard, and can be Real-time, Store-and-Forward, or empty) 54 System Management Guide Managing the MX Message Standards • Obsolete ("True" indicates that a message has been removed from the standard). 6.2 Install an MX Message Standard Prerequisites You must receive a message standards deployment package for the Message Standard in question and a Digest for the Message Standard. To install a Message Standard: 1. Start the Alliance Access servers in housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Message Standards. The Message Standards main window appears. 4. From the Message Standards menu, select Install. The Install Message Standards dialog box appears. Enter the location and name of the deployment package (ZIP file) that contains the MX Message Standards), or use the browse button ( ... ) to locate it. If the file is not located on the current drive, then enter the drive name first. 5. Click Install . The Install Message Standards window appears: 15 July 2011 6. Compare the digest displayed with the one you received separately from SWIFT. 7. If the digests are the same, then click Continue to install the message standard. If the message standards are installed successfully, then an event is logged. The event entry contains the digest for the standard. 55 Alliance Access 7.0.20 6.3 Remove an MX Message Standard To remove a Message Standard: 56 1. Start the Alliance Access servers in housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Message Standards. The Message Standards main window appears. 4. Select the required standard in the list and then select Remove in the Message Standards menu. You are now prompted to confirm the removal. 5. Click OK to complete the operation and remove the Message Standard from the database. System Management Guide Installing Value-Added Services 7 Installing Value-Added Services Introduction This section contains instructions for installing and activating a value-added service, such as FIN Copy, using the SWIFT Support application. SWIFT provides these services to certain National banking communities. Domestic interbank transactions, in the form of FIN messages, are copied automatically (by SWIFT) to, or by means of a defined Central Institution. The use of value-added services facilitates the clearing, and settlement of payments or securities, and the consolidation of other financial information. Except for the initial configuration of the parameter files, no extra manipulation of the user interface is required to send and receive copy service messages. You can install several value-added services with the same service name. Note 7.1 To perform the tasks described in this section, the Alliance Access servers must be restarted in housekeeping mode. You also require a specific operator entitlement which, by default, is granted within the "SuperKey" and "Supervisor" operator profiles. FINCopy Service Overview To use the FINCopy service, you must, in addition to the normal Alliance Access configuration: • complete the necessary registration procedures with your central institution • install a FINCopy service parameter file into Alliance Access • assign the FINCopy service to the LTs (own destinations) to be used to send and receive copy messages • specify whether message authorisation (RMA) is required (default is "not required") • activate the relevant FINCopy service in Alliance Access. Messages sent using FINCopy services are known as Copy Service Messages. These messages are recognised by SWIFT Support Services by the presence of field tag 103 in block 3 of the message - the user header block. FINCopy can operate in the following modes: • Y-Copy mode • T-Copy mode • Bypassed. 15 July 2011 57 Alliance Access 7.0.20 7.1.1 Y-Copy Mode Overview In Y-Copy mode, messages are intercepted by the Y-Copy facility. Y-Copy either authorises the message and delivers it to the recipient or rejects the message, for example, aborts the copy process and notifies the sender. Y-Copy is the default mode for the FINCopy service on Alliance Access. Central Institution Destination Sending Institution SWIFT Network Receiving Institution D0540048 Y Copy Facility Before the message is delivered to the receiving institution, the Copy Service sends a partial, or a full copy of the message to the central institution. The central institution analyses the information contained in this message. Based on internal calculations, the central institution decides whether the copy service can release the message to the receiving institution. In this way, the receiving institution only receives authorised messages. A Proprietary Authentication Code (PAC) trailer may be appended to the message before delivery. 58 System Management Guide Installing Value-Added Services 7.1.2 T-Copy Mode Overview In T-Copy mode, messages are only copied to the central institution. The recipient receives the message independently of any authorisation from the central institution. Central Institution Destination Sending Institution SWIFT Network Receiving Institution D0540049 T Copy Facility A Proprietary Authentication Code (PAC) trailer is not appended to the message before delivery. 7.1.3 Bypassed Overview This mode is essentially used in disaster situations. In bypassed mode, no copying to the Central Institution Destination (CID) is performed. Messages are still intercepted by the copy service, but they are not copied to the central institution. Subsequently, no authorisation is required before the message is delivered. A Proprietary Authentication Code (PAC) trailer is still appended to the message before delivery, but it is empty to signify to the recipient that the message has not been authorised by the central institution. 7.2 Installing and Removing Value-Added Service Parameter Files Overview Before using a value-added service, the required value-added service parameter file must be installed in Alliance Access. Each file defines the nature of the service in participating countries, the identity of the relevant Clearing Institution and determines the message types and fields to be copied when using the value-added service. Following successful installation, the relevant value-added service must be activated in Alliance Access. Note 15 July 2011 For T-Copy mode, only participants have to install the value-added service parameter file. The central institution does not have to install it. 59 Alliance Access 7.0.20 7.2.1 Installing a Value-Added Service Parameter File To install a value-added service parameter file: 1. Start the Alliance Access servers in housekeeping mode. 2. Run the SWIFT Support application. 3. From the Value-Added Service menu, select Install. The Install Value-Added Service window appears. 4. In the Application Service Profile Package field, enter the location and name of the file (ZIP file) that contains the FIN Copy Profile to be installed (or use the browse button ( ... ) to locate it). If the file is not located on the current drive, then enter the drive name first. For more information, see "Managing Application Service Profiles" in the Installation and Administration Guide. 5. Click Continue . The following values are displayed for the FIN Copy profiles: • Name: 3-character code of the FIN Copy profile • Central Institution: the BIC8 of the Central Institution • Live: Indicates that the FIN Copy profile is live. • Environment: the environment to which the FIN Copy profile refers (Production or ITB) 6. Select the FIN Copy Profile. 7. Click Note 7.2.2 Install . If you are running Alliance Access in Low Speed Mode, then you must singleclick the Value-Added Service window or press F5 to refresh it. Removing Value-Added Service Parameter Files Overview Existing value-added files may be uninstalled to remove from the system a value-added service which you no longer need, or which you have installed by mistake. To remove a value-added service parameter file: 60 1. Start the Alliance Access servers in housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Value-Added Service. The Value-Added Service window appears, displaying the list of defined services. System Management Guide Installing Value-Added Services 4. Select the service that you want to remove. 5. From the Value-Added Service menu, select De-install. Note 7.3 If you are running Alliance Access in Low Speed Mode, then you must singleclick the Value-Added Service window or press F5 to refresh it (Windows servers only). Activating and Deactivating Value-Added Services Overview A value-added service must be activated before it can be used in Alliance Access, for example, after the value-added file has been installed or after the service has been previously deactivated. An active value-added service may be suspended by deactivating that service. Note 7.3.1 For T-Copy mode, only participants have to activate a value-added service. The central institution does not have to perform this task. Activating a Value-Added Service Overview Before attempting to activate a value-added service, ensure that the required value-added service parameter file has first been installed. For more information, see "Installing a ValueAdded Service Parameter File" on page 60. To activate an installed value-added service: 7.3.2 1. Start the Alliance Access servers in housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Value-Added Service. The Value-Added Service window appears, displaying the list of defined services. 4. Select the service that you want to activate. 5. From the Value-Added Service menu, select Activate. The State field in the ValueAdded Service window changes to Active for the selected service. Deactivating a Value-Added Service Overview A previously activated value-added service may be deactivated if it is required to suspend the use of a particular value-added service for some reason. Deactivation does not physically remove the service from the system, but causes it to become unavailable. 15 July 2011 61 Alliance Access 7.0.20 To deactivate an active value-added service: 1. Start the Alliance Access servers in housekeeping mode. 2. Run the SWIFT Support application. 3. From the View menu, select Value-Added Service. The Value-Added Service window appears, displaying the list of defined services. 4. Select the service that you want to deactivate. 5. From the Value-Added Service menu, select Deactivate. The State field in the ValueAdded Service window changes to Inactive for the selected service. Following the deactivation of a value-added service, this service may once again be activated, or may be removed altogether. 7.4 Assigning a Value-Added Service to a Destination Overview To send and receive copy service messages using a particular value-added service, the required service must be assigned to a destination on your system. Note A destination cannot be assigned more than one value-added service with the same name. To assign a value-added service to a destination: 1. Run the SWIFT Support application. 2. From the View menu, select Value-Added Service. The Value-Added Service window appears, displaying the list of defined services. 3. Ensure that the value-added service is "inactive". No destination may be assigned to the service while it is in the "active" state. For more information, see "Deactivating a ValueAdded Service" on page 61. 4. Select the required service. 5. From the Value-Added Service menu, select Destinations. The Own Destination dialog box appears. For a description of the fields displayed in this window, see "Value-Added Service Destinations Window" on page 63. 62 6. To assign a destination to the selected service, select the destination in the Available list pane and then move it into the Selected list pane. 7. From the Value-Added Service menu, select Modify. System Management Guide Installing Value-Added Services Warning A warning dialog box appears if: • The selected service does not exist • A selected destination is already assigned to the service • There is a difference between the status of the copy service and the selected destination, that is, destination is T&T and copy service is "live", or vice versa. To de-assign a value-added service from a destination: Undoing the assignment between a value-added service and a destination is achieved by selecting the destination in the Selected list and then moving it into the Available list. 7.5 Value-Added Service Destinations Window Description From the Value-Added Service menu, select Destinations. The Value-Added Service Destinations dialog box appears. Example of Value-Added Service Destinations window Field descriptions Service Name Displays the name of the service. Central Institution Displays the BIC8 of the Central Institution. 15 July 2011 63 Alliance Access 7.0.20 Service Definition Shows the operational status of the service. There are two possibilities: • Live • Test & Training (T&T). Identifies the selected destination as a live service or a test and training service. Test and training destinations are identified by a "0" as the eighth character of the BIC (for example, BANKUS80). Service State This field displays the current enable state of the service. The value shown in this field is set after issuing either the Activate and Deactivate commands. RMA Authorisation This field indicates whether message authorisation is required or not for the service. Two values can be displayed: • Required • Not Required Own Destination A standard set of transfer list panes labelled Available and Selected. These two lists combined contain all the licensed live destinations (own destinations) currently installed on your system. 64 System Management Guide Assigning Routing Keywords 8 Assigning Routing Keywords Introduction This section contains instructions for assigning the routing keywords on any field of the message text, using the SWIFT Support application. Routing keywords, defined using the Routing application, must be assigned to a specific message syntax table and can also be assigned to fields in specified message types. Normally, the names and types of routing keywords is already defined using the Routing application. For more information, see "Routing Keywords" on page 317. For more information about the Routing application, see "Message Routing" on page 314. 8.1 Procedure for Assigning Routing Keywords To assign routing keywords: 15 July 2011 1. Run the SWIFT Support application. 2. From the View menu, select Routing Keyword. The Routing Keyword window appears, displaying the list of defined routing keywords and assigned message syntax tables. 3. From the Routing Keyword menu, select New. The Routing Keyword Details dialog box appears. 65 Alliance Access 7.0.20 4. Keywords are already defined in the Routing application. For more information, see "Routing Keywords" on page 317. Click the Routing Keyword option button to select the routing keyword to be assigned. The Description and Type fields display the details of the keyword. 5. Click the Mstv Id option button to select the required message syntax table version. 6. In the Route on pane, specify the precise SWIFT message field that is to be mapped to the keyword in the Field Tag field. 7. If the SWIFT message field has subfields, then it is possible to select a specific subfield to map to the keyword using the Select option button. When the field or subfield has been selected, its expansion and syntax appear. It is also possible to place the keyword in the middle of a field or subfield by entering the line and column range. 8. The Messages pane displays the SWIFT message types which contain the SWIFT message field and for which the keyword is valid. Select the required SWIFT message types by moving messages from the Available to the Selected list panes by selecting them and clicking the forward arrow. You can move messages back from the Selected list pane to the Available list pane by selecting them and clicking the reverse arrow. 9. From the Routing Keyword menu, select Add to assign the routing keyword to the selected message types. Note The routing keyword is not used for routing until the servers have been restarted in operational mode. You cannot assign a keyword of type Amount to a free format text field. 66 System Management Guide Modifying Active Routing Rules 9 Modifying Active Routing Rules Introduction This section contains instructions for modifying the rules of the active routing schema, using the Routing application. 9.1 About Modifying Active Routing Rules Overview Routing schemas are used to group routing rules for activation within the system. Each routing rule may be a member of several schemas, or belong to none. However, only rules that belong to the "active" schema are used for processing. Only one schema can be active at a time. Note To modify the rules, add new rules or delete existing rules of the active routing schema, the Alliance Access servers must be restarted in housekeeping mode. Once a change has been made to the routing rules and assigned to a particular schema, the schema is deactivated. It must then be reactivated so that the servers can be restarted in operational mode. For more information about activating schemas, see "Approving and Activating a Routing Schema" on page 316. If you want to change a schema that is already "active" without switching to housekeeping mode, then you must duplicate the schema and make changes to the duplicate. This allows you to modify routing rules in operational mode. To apply the changes you have made to the routing rules, the duplicate schema must be made active. For information about modifying, adding or deleting rules for an active routing schema, see "Routing Rules" on page 318. The Routing application is used to perform these tasks. 15 July 2011 67 Alliance Access 7.0.20 68 System Management Guide Part C - Configuring Alliance Access Part C Configuring Alliance Access 15 July 2011 69 Alliance Access 7.0.20 70 System Management Guide Starting, Stopping, and Restarting the Servers 10 Starting, Stopping, and Restarting the Servers Introduction This section describes the two modes in which the Alliance Access servers work, that is, housekeeping and operational. It also explains how to stop and restart the servers manually. For information about how to stop and restart the servers automatically, see "Configuring the Calendar and Scheduling Processes" on page 185. Note On UNIX systems, you can start Alliance Access automatically whenever the system is booted. This is achieved by setting the system parameter Startup Mode to Automatic in the System Management application. For more information, see "Modifying Parameters" on page 158. For this parameter setting to take effect, the bootstrap service must be configured to start at boot time. This is configured using the saa_configbootstrap tool, described in the Installation and Administration Guide. On Windows systems, if you want Alliance Access to start at boot time, then you must make Alliance Access run as a service and configure (via the Windows Service Management interface) the Alliance Access Bootstrap service to start automatically. Running Alliance Access as a Windows Service is achieved by setting the system parameter 'Startup Mode' to 'Service' in the System Management application. For more information, see "System" on page 169. When Alliance Access is started as a Service, mapped network drives cannot be used. You use the System Management application to stop and restart the servers. 10.1 Housekeeping Mode and Operational Mode Overview Alliance Access can run in the following modes: • Operational: This is the normal multi-user mode for operating Alliance Access, allowing all functions of Alliance Access to be used. It is the default operating mode. • Housekeeping: This is a maintenance mode where, by default, only one user can be signed on to Alliance Access at a time. Queues are frozen and messages cannot be sent or received. The following tasks can only be performed in housekeeping mode: – install a Message Syntax Table – install Message Standards – define logical terminals – install value-added services 15 July 2011 71 Alliance Access 7.0.20 – modify active routing rules No scheduled processes take place when the servers are running in housekeeping mode. Note You use the System Management application to stop the servers. To change mode, the Alliance Access servers must already be running. You also use the System Management application to restart the servers. 10.2 Starting the Alliance Access Servers Overview Before you can run Alliance Access, you must start the servers. To start the Alliance Access servers: 1. Log on to Windows as an Administrator. 2. Click Start and select Programs/Alliance Access/System Administration. 3. Double-click the Start Alliance icon. The following dialog box appears: 4. Select: • Operational Mode to perform operational tasks • Housekeeping Mode to perform maintenance and security tasks. 10.3 5. Click OK to start the servers. After a while, a message appears telling you that the servers have started. 6. Click OK to clear the message. Stopping the Alliance Access Servers Overview You must shut down Alliance Access before loading a patch or performing any offline backup, file reorganisation, or system upgrade. To stop the Alliance Access servers manually, you must be signed on at the Alliance Access server or Alliance Workstation. If a calendar has been created, then you can schedule the servers to stop automatically. See "Scheduling Alliance Access Servers to Stop". Note 72 If there is no active routing schema when stopping the Alliance Access servers, then a restart is only possible in housekeeping mode. System Management Guide Starting, Stopping, and Restarting the Servers To stop the Alliance Access servers: 1. Run the System Management application. 2. From the File menu, select Stop Alliance. The Stop Alliance window appears. 3. Select Manual as the Stop operating mode option. 4. Click Stop . When you click Stop , an alarm is broadcast to all operators who are signed on, to warn them of the impending shutdown. Once the system is shut down, no more message processing is allowed and offline utilities can be run to perform additional system management functions. 10.4 Restarting the Alliance Access Servers Overview To restart the Alliance Access servers manually, you must be signed on at the Alliance Access server or Alliance Workstation. If a calendar has been created, then you can schedule the servers to restart automatically. For more information, see "Scheduling Alliance Access Servers to Restart". To restart the Alliance Access servers: 15 July 2011 1. Run the System Management application. 2. From the File menu, select Restart Alliance. The Restart Alliance dialog box appears. 3. Select Manual as the Restart Operating Mode option. 73 Alliance Access 7.0.20 4. Select either Operational or Housekeeping as the Restart mode option. 5. Click Note Restart . Changes to some system parameters do not take effect until the servers have been stopped and restarted. Each restart involves a shutdown of the servers, followed by an automatic start in the selected operating mode. Following any maintenance work in housekeeping mode, you must use the Restart Alliance command again to restart Alliance Access in operational mode. 10.5 Extended Reporting at Startup of Alliance Access Overview To help with the investigation of startup problems, Alliance Access displays server/database interaction during startup in the System Administration window. At the same time, this output is also written to the startup log file. In this way, a user can simply print out the startup log file and send it to SWIFTSupport. To use this feature, select Extended Reporting in the Alliance Start Servers window. For more information, see "Extended Reporting at Server Startup" in the Installation and Administration Guide. 10.6 Stopping and Restarting Components Overview This section explains how to stop and restart Alliance Access components. Note If you have licence option 07:STANDALONE REC, then 'SIS SWIFT Interface Services' and 'SNIS SWIFTNet Interface Services' do not appear in the list of components. 10.6.1 Stopping Components in Operational Mode Overview In operational mode, you can stop components as explained in the following procedure. 74 System Management Guide Starting, Stopping, and Restarting the Servers To stop a component in operational mode: 1. Run the System Management application. 2. Select Stop Component from the File menu. The Stop Component window appears. 3. Click the component that you want to stop in this window and click Stop . 10.6.2 Starting Components in Operational Mode Overview In operational mode, you can restart components that were stopped as explained in the following procedure. To start a component in operational mode: 1. Run the System Management application. 2. Select Start Component from the File menu. The Start Component window appears. 3. Click the component that you want to restart in this window and click Start . 10.6.3 Stopping Components in Housekeeping Mode Overview Alliance Access, running in Housekeeping Mode, allows you to prevent components from starting, when the servers are restarted in operational mode. To do this, use Stop Component in housekeeping mode. 15 July 2011 75 Alliance Access 7.0.20 You can prevent the SWIFT Interface Services (SIS), SWIFTNet Interface Services (SNIS), SWIFTNet Support Services (SNSS), Application Interface Services (MXS), or any ADK components from starting up when restarting the Alliance Access servers in operational mode by using the following procedure. To stop components in housekeeping mode: • 76 From the System Management application, select the components that you want to stop and click Stop Component from the File menu. System Management Guide Managing Alliance Access Security 11 Managing Alliance Access Security Introduction This section describes how to set up the various security-related features, such as operator definitions profiles and entitlements, which must be configured before using Alliance Access. The Security Definition application strictly controls the use of Alliance Access. Security officers use this application to create and manage operator definitions. When an operator signs on, their operator definition determines every aspect of what they can do with the system. Security officers also use the Security Definition application to modify the global security parameters that control access to the system. 11.1 Listing Components Component View The component view of the Security Definition application lists all registered components with their version number. The component details are editable for Alliance Developers Toolkit applications only, and allow for unit re-assignment if required. 11.1.1 About Listing Components Overview When you select Component from the View menu of the Security Definition application, all the components are listed. The Component column shows the name of each component. The Version column shows the version number of the component. 15 July 2011 77 Alliance Access 7.0.20 11.1.2 Displaying Component Details To display component details: 1. From the View menu of the Security Definition application, select Components. 2. Double-click the name of the component to display its details. General Info tab The General Info tab displays the following details: Field Description Name The name of the component Description A description of the component Version The version number of the component Type The component type. For an Alliance component, this is Alliance. ADK tab The ADK tab is present if the optional package 99:TOOLKIT RUN-TIME is licensed, and if the component was installed using the Alliance Developers Toolkit. Field Description Assigned Units The unit _ALL_ is assigned by default to an ADK component, which indicates that there are no restrictions by unit for this ADK component. Allowed Categories The categories that the Alliance Developers Toolkit may use. Category Functions The list of functions within the category. For more information, see the Installation and Administration Guide or the documentation provided with the Alliance Developers Toolkit. 11.2 Defining Units Overview Units allow operators, working in a large institution, to be subdivided into logical working groups. This means that confidential message information such as value dates, currency, amounts, and message text are visible only to those operators with the appropriate unit membership. When an operator belongs to a unit, they can assign specific messages to that unit during creation or modification. When a message has been assigned to a unit, only those operators 78 System Management Guide Managing Alliance Access Security who belong to that same unit can view confidential information such as value date, currency and amount. The system generates the unit None by default. The Security Officers (LSO and RSO) cannot create units. 11.2.1 Defining a Unit To define a unit: 1. Run the Security Definition application. 2. Select Unit from the View menu. 3. To create a unit, either: • select New from the Unit menu, or • select an existing unit and base the new unit on it, by selecting New As from the Unit menu. 4. In the Name field, type the name of the unit. 5. In the Full Description field, enter a description of the unit. The description may be up to 24 characters. 6. From the Unit menu, select Add. The new unit has the status Unapproved. 7. After a unit has been defined, it must be approved before it can be assigned to an operator or a message instance. To approve a unit, select Approve from the Unit menu. If you do not have the entitlements to approve units, then ask an appropriate operator (for example, the System Administrator) to do it. Note Once a unit has been approved, it cannot be unapproved or removed from the system. 11.2.2 Removing Unapproved Units To remove an unapproved unit: 15 July 2011 1. Run the Security Definition application. 2. To display existing units, select Unit from the View menu. 3. Select the unit that you want to remove. The unit must have the status Unapproved. 4. From the Unit menu, select Remove. Alliance Access asks you to confirm the removal. 79 Alliance Access 7.0.20 Note 11.3 You can save your current window settings by selecting Save Current Settings from the File menu. The next time that you start the Security Definition application, these settings are used automatically. Operator Profiles Overview Alliance Access profiles are assigned to operators to entitle them to work with the system. A single operator can be assigned several profiles. Each profile gives the operator access to one or more applications. Applications have functions available and some of these functions have a further level of entitlement, known as permissions. The general functions of most applications allowed by a profile are automatically available to operators and consequently do not appear in the list of functions. For example, any operator who is given access to the Event Journal application can use the application to carry out searches in the Event Journal. Profiles can be added, modified, and removed from the system. Default profiles are supplied with Alliance Access to illustrate the recommended way of allocating entitlements. The Profile window lists these default profiles. Note The default profiles provided by Alliance Access are described in Appendix A, "Default Profiles" on page 369. To list operator profiles and details: 80 1. From the View menu of Security Definition, select Profile to display the list of profiles. 2. Double-click a profile (for example, R7.0_MsgEntry). The Profile Details window appears. System Management Guide Managing Alliance Access Security Some applications are in the Applications/Available column and some are in the Applications/Selected column. Operators who are assigned this profile can only access the applications in the Applications/Selected column. You can select other profiles from the Profile window while the Profile Details window is open. If you do so, then the details of the profile that you selected appear within the Profile Details window. This is a fast way of seeing all the profile details. 15 July 2011 3. Click an application in the Applications/Available and Applications/Selected column. The functions for the application appear in the Functions/Available and Functions/ Selected columns. For example, the Message Creation application has the functions Add/ Mod/Rem Template, Override Test Require, Route Message, Create Message and Dispose Message. 4. Functions with an asterisk (*) next to their names have permissions associated with them. Click one of these functions in the Functions/Selected column (for example the Dispose Message function). 5. Select Permissions from the Profile menu or double-click Dispose Message in the Selected column. 81 Alliance Access 7.0.20 Permissions provide a further level of detail about exactly what an operator is entitled to do. For example, the Dispose Message function has permissions that describe exactly which types of message can have their approval bypassed. Permissions are usually expressed in one of three ways: • a Yes or No flag • an actual value, such as a time • a list of one or more values (such as message types) that are either Prohibited or Allowed. Prohibited and Allowed are used as follows: • If you select Prohibited, then the column to the right of the field can be used to specify a range of values that is prohibited, such as destinations or message types. • If you select Prohibited and enter nothing in the column, then nothing is prohibited, that is, everything is allowed. • If you select Allowed, then the column can be used to specify a range of values that is allowed. • If you select Allowed and enter nothing in the column, then nothing is allowed, that is, everything is prohibited. For example, the previous screen shows the first few permissions for the Dispose Message function within the Message Creation application. These permissions mean that an operator with the R7.0_MsgEntry profile has the following restrictions when trying to bypass approval for newly created messages: 82 Permission Description Bypass Verification CCY/Amount Prohibited is selected and the column to the right is empty. This means that nothing is prohibited. The operator can bypass verification for a message of any currency and any amount. System Management Guide Managing Alliance Access Security Permission Description Bypass Authorisation CCY/Amount Prohibited is selected and the column to the right is empty. This means that nothing is prohibited. The operator can bypass authorisation for a message of any currency and any amount. Bypass Verification SWIFT FIN User MT Allowed is selected and 999 appears in the column to the right. This means that the operator is only allowed to bypass verification for Message Type 999. There are other permissions for the Dispose Message function, but these are not shown on the example screen or in the permissions table. For complete details of the default profiles and their associated applications, functions and permissions, see Appendix A, "Default Profiles" on page 369. 11.4 Modifying Operator Profiles Overview This section describes how to modify operator profiles. Note If you modify a profile that is already assigned to one or more operators, then all operators using that profile become Unapproved. The left security officer and right security officer, or operators with the appropriate approval entitlement, must approve the operators again. For more information, see "Approving and Enabling Operator Definitions" on page 90. To modify a profile: 1. From the View menu of Security Definition, select Profile. 2. Double-click the profile. 3. Select the applications that you want the profile to contain from the Applications/Available column. 4. Click the transfer button to move the applications that you have selected from the Available column into the Selected column. To move an application out of the Selected column back to the Available column, select it and click the reverse transfer button. Note 5. Click an application in the Selected column to see whether it has related functions. If the application does have functions, then they appear in either the Available or Selected columns. You can move functions between the two columns by selecting them and clicking the transfer arrow or the reverse transfer arrow. If a function has an asterisk against it, then it has permissions which you can also change, to restrict operators' access to that function. Note 6. 15 July 2011 You cannot transfer applications between the Selected and Available lists by double-clicking them. You cannot transfer functions between the Selected and Available columns by double-clicking them. If you double-click a function in the Selected list, and that function has permissions, then the Permissions Details window appears. From the Profile menu, select Modify. 83 Alliance Access 7.0.20 Note 11.5 During an upgrade, profiles remain unchanged even if Applications or Functions have been modified. Adding New Operator Profiles Overview There is no restriction on the number of new profiles that you can define. To add a new profile: 1. Either select New from the Profile menu, or if you want the new profile to be based on an existing profile, select the existing profile and select New As from the Profile menu. 2. In the Name field, type a name. This name must be unique and can have up to 150 alphanumeric characters. 3. Select the applications that you want the profile to contain from the Applications/Available column. 4. Click the transfer button to move the applications that you have selected from the Available column into the Selected column. To move an application out of the Selected column back to the Available column, select it and click the reverse transfer button. 84 5. Click an application in the Selected column to see whether it has related functions. If the application does have functions, then they appear in either the Available or Selected column. You can move functions between the two columns. If a function has an asterisk against it, then it has permissions which you can also change. 6. From the Profile menu, select Add. System Management Guide Managing Alliance Access Security 11.6 Predefined Operators and New Operators Overview Alliance Access is installed with two predefined operators: • Left security officer • Right security officer The left security officer and right security officer operators are initially used to define other operators. Each operator that you define has a current status which indicates whether they can use the system. Until a new operator is approved separately by both security officers, they cannot sign on. Before you approve new operators, you must assign profiles to them. Profiles are entitlements to work with Alliance Access. Any number of operators can share the same profiles, to reflect the fact that the duties, and responsibilities that involve Alliance Access can be shared within your institution. The name, current status, and assigned profiles that an operator has are called an operator definition. To help you define new operators, a number of default profiles are supplied. When you define a new operator, you can assign one or more of these default operator profiles to the new operator definition. These profiles cannot share the same applications however. If none of the default operator profiles provides the Alliance Access entitlements that you require, then you can either modify an existing profile or create a profile based on an existing one. Entitlements to define, modify, or remove operators can all be assigned to other operators. The ability to give left or right-approval (but not both) to other operators is also an entitlement which can be assigned to other operators. An operator with the left or right-approval entitlement can display and print the details of the left or right half respectively of an operator's system password, and can also reset that operator's user password. For details, see "Approving and Enabling Operator Definitions" on page 90. Existing operator definitions can have profiles added or taken away from them, apart from the profiles for left security officer and right security officer, which are fixed. The profiles for left security officer and right security officer are not visible within the Security Definition application. If you modify an existing operator definition, then the left security officer and right security officer, or operators with the appropriate approval entitlements, must approve it again before the relevant operator can sign on. 11.7 Defining Operators Overview You must define at least one completely new operator using the New command. Note If you use LDAP to authenticate users (user name and password verification), then see "LDAP User Authentication" in the Security Guide for more information. To define an operator: 15 July 2011 1. Run the Security Definition application. 2. If operators do not appear, then select Operators from the View menu. 3. Either select New from the Operator menu, or if you want the new operator's details to be based on those of an existing operator definition, then select the operator and select New As from the Operator menu. 85 Alliance Access 7.0.20 4. In the Name field, enter a name for the operator. This name can have up to 150 alphanumeric characters. The following characters are allowed: @, ., _, -, :. SWIFT recommends selecting something simple, such as the operator's first name, because they must enter it in the Operator Name field each time they sign on. The operator must be told this name. 5. In the Full Name field, enter the full name of the operator. As this is a new operator, the Approval Status is Unapproved and the Enable Status is Disabled. 6. In the Authentication Method field, select a method for authenticating users. Three authentication methods exist: • Local. The user name and password are stored in the Alliance Access database. • One-time Password. The password of the user is validated against an authentication server. • LDAP. The user name and password are validated against an LDAP authentication server. If you select LDAP, the LDAP User Identifier field appears. In this field, specify the user name of the operator as defined in the LDAP directory. If you leave this field empty, then the local Alliance Access operator name is forwarded to the LDAP server and used for the authentication. You can enter the same LDAP User Identifier for multiple operators. This allows for multiple operator profiles having one LDAP user. The mapping between operator and LDAP user allows for a gradual migration to LDAP 7. 86 Select the Application check box if the user being defined is an application that will connect to Alliance Access. System Management Guide Managing Alliance Access Security Note Application operators cannot use OTP or LDAP. The password of an Application operator can only be regenerated by the Security Officers using the Reset User Pwd function in the Security Definition application. Assign profiles and units 1. Assign one or more profiles to the operator definition. Click the Profiles & Units tab. This tab appears only if a specific package is licensed. The available profiles appear in the Allowed Profiles/Available column. The list includes the predefined profiles supplied with Alliance Access. If the security configuration parameter "Restrict Delegation" is set to Yes and you are not a right security officer or left security officer, then in some cases you can only select from a predefined subset of available profiles. If you have defined your own profiles, then these also appear in the Allowed Profiles/ Available column. For information about the default profiles provided, see Appendix A, "Default Profiles" on page 369. 2. Select the profiles that you want to assign to the operator from the Allowed Profiles/ Available column. Click the transfer button to move the operator profiles that you have selected from the Allowed Profiles/Available column into the Allowed Profiles/Selected column. To move an operator profile out of the Allowed Profiles/Selected column back to the Allowed Profiles/Available column, select it and click the reverse transfer button. Note 15 July 2011 Each profile that you move into the Selected list must not conflict with any other selected profiles in terms of application functions and permissions. For example, you must not assign two profiles to an operator if one profile allows the operator to sign on at any time and the other only allows sign on during working hours (the Access Control application controls sign-on times). Alliance Access checks that there is no conflict between the profiles assigned to an operator at the time that you add, modify, approve, or enable an operator definition. 87 Alliance Access 7.0.20 3. You can assign one or more units to an operator. Select the units that you want to assign to the operator from the Assigned Units/Available column. The range of units available for assignment depends on the setting of the Operator: Restrict Functions parameter. For more information, see "Restricting Operator Functions" on page 112. Click the transfer button to move the units that you have selected from the Assigned Units/ Available column into the Assigned Units/Selected column. To move a unit out of the Assigned Units/Selected column back to the Assigned Units/Available column, select it and click the reverse transfer button. The unit None is a system-generated unit and is assigned to all new operators by default. If required, it can be unselected. To assign printers (UNIX servers only): • To assign a printer to an operator, select a printer from the Allowed Printers/Available column and move it to the Allowed Printers/Selected column. Note The available printers are defined using the System Management application. For more information, see "Defining New Printer" on page 124. To add the defined operator: • 11.8 From the Operator menu, select Add. Setting Up Local Security Officers Overview The service bureau left security officer and right security officer can create "local" security officers for each of the SWIFT user institutions operating through the bureau. To allow this, the security configuration parameter Restrict Delegation must be set to Yes. The scope of Operator Profiles, Units, and Destinations that a local security officer can assign to other operators can be limited to a subset defined by the left security officer and right security officer. These subsets are designed by the left security officer and right security officer to ensure that operators only have access to their own traffic data, that is by specifying particular profiles (which give access only to particular message partners, exit points, and routing queues), units and destinations. This feature is known as "Delegation" and supports the strict segregation of traffic data between institutions using the service bureau. Note The left security officer and right security officer can create an operator profile which may prohibit or allow access to a selected list of message partners, exit points, or routing points. This feature is provided respectively by the Open/Print Partner, Open/Print Exit Point, and Open Routing Point functions of the Application Interface. To activate the delegation feature, the following security configuration parameter must be set in the Security Definition application: Restrict Delegation = Yes When this parameter is set to Yes, a third tab called Delegations is available to the left security officer and right security officer in the selected Operator Details window. When the parameter is set to No, then this tab is not visible and therefore the subset assignments are not valid. 88 System Management Guide Managing Alliance Access Security 11.8.1 Creating a Local Security Officer Profile To create a local security officer profile: 1. Sign on as left security officer or right security officer. 2. For each SWIFT user institution using the service bureau two local security officer profiles, left and right, must be created. Go to "Adding New Operator Profiles" on page 84. Carry out steps 1 to 6. Note You have to decide which applications and associated functions your local security officers have to access. Remember to add the Security Definition application. You must add the associated permission for approving operators (one profile for left, a second similar profile for the right). When the Restrict Delegation parameter is set to Yes, new operator profiles must be set up with allowed destinations, and existing operator profiles must be changed to include the allowed destinations. Prohibited destinations are not supported in this case. The list of allowed destinations in the operator profile must contain BIC8 destinations and no wildcards. 11.8.2 Creating a Local Security Officer To create a local security officer: 1. Sign on as left security officer or right security officer. 2. Check that the security configuration parameter Restrict Delegation is set to Yes. 3. Define the local left security officer as a new operator. Go to "Defining Operators" on page 85. When assigning profiles for the left local security officer, include the corresponding left security officer profile that you created in "Creating a Local Security Officer Profile" on page 89. 4. Click the Delegations tab. Specify the delegated Operator Profiles, Units, and Destinations that this particular local security officer can assign to other operators. The selections made restrict the local security officer's choice when operator profiles are created. When creating or modifying an operator profile, the inclusion of a non-delegated item results in an error message. 15 July 2011 89 Alliance Access 7.0.20 5. Select the Delegated profiles that you want to assign to the operator from the Available list. 6. Click the transfer button to move the operator profiles that you have selected from the Available list into the Selected list. To move an operator profile out of the Selected list back to the Available list, select it and click the reverse transfer button. 7. Select the Delegated Units that you want to assign to the operator from the Available list. 8. Click the transfer button to move the units that you have selected from the Available list into the Selected list. To move a unit out of the Selected list back to the Available list, select it and click the reverse transfer button. 9. Select the Delegated Destinations that you want to assign to the operator from the Available list. 10. Click the transfer button to move the destinations that you have selected from the Available list into the Selected list. To move a destination out of the Selected list back to the Available list, select it and click the reverse transfer button. 11. Click Add/Modify. 12. Approve and Enable the local security officer. See "Approving and Enabling Operator Definitions" on page 90. When the local security officer logs in and selects the Security Definition application, only the delegated profiles and units are available for Operator definition. 13. Repeat the process from step 1 for the right local security officer. 11.9 Approving and Enabling Operator Definitions Overview The operator definition must be approved and enabled. The left security officer and right security officer performs this task. However, an operator can act as left security officer or right security officer and take part in approving and enabling other operators if necessary. 90 System Management Guide Managing Alliance Access Security By default, left security officer can left-approve an operator, and right security officer can rightapprove an operator. The Approve Operator entitlement can also be assigned to other operators. The entitlement includes a permission that either allows a user to left-approve other operators or right-approve other operators. An operator cannot have permission both to leftapprove and to right-approve other operators at the same time. An operator who is given the Approve Operator entitlement and permission to left-approve an operator can also display and print the left half of an operator's system password. Similarly, an operator with the entitlement to right-approve an operator can display and print the right half of an operator's system password. Any operator that can left-approve or right-approve operators can also reset an operator's user password, except for the left security officer and right security officer operators' passwords. Note If your operators are using One-Time Passwords (OTP) or LDAP authentication, then this section is not applicable. 11.9.1 Approving and Enabling Operator Definitions as the Left Security Officer Tasks for left security officer, or an operator with entitlement and permission to left-approve: 1. Sign on to Alliance Access. 2. Double-click the Security Definition icon. 3. From the View menu, select Operator. 4. From the Operator menu, select View and select both Approval Status and Enable Status. The new operator appears in the list as Unapproved and Disabled. 5. Double-click the new operator. 6. From the Operator menu, select Approve. The Approval Status changes to Wait RSO Approval. 7. Check mark the Display Password box to the right of the Auto Password field. A twocharacter, case-sensitive password appears. Note the password and pass it secretly to the operator for whom the definition is being created. 8. Sign off. 11.9.2 Approving and Enabling Operator Definitions as the Right Security Officer Tasks for the Right Security Officer, or an operator with entitlement and permission to rightapprove: 15 July 2011 1. Sign on to Alliance Access. 2. Double-click the Security Definition icon. 3. From the View menu, select Operator. 4. From the Operator menu, select View and select both Approval Status and Enable Status. The new operator appears in the list as Wait RSO Approval and Disabled. 91 Alliance Access 7.0.20 5. Double-click the new operator. The Operator Details window appears. 6. From the Operator menu, select Approve. The Approval Status changes to Approved and the Enable Status changes to Enabled. 7. Check mark the Display Password box to the right of the Auto Password field. A twocharacter, case-sensitive password appears. Note the password and pass it secretly to the operator for whom the definition is being created. 11.10 Modifying Operators Overview You can modify the details for an existing operator. When you modify details, the operator becomes Unapproved, and the left security officer and right security officer, or operators with the appropriate approval entitlements, must approve the operator again. Effect on passwords If user passwords are used on your system, then the modified operator can continue to sign on with an existing password. If you are using one-time passwords: • If you change the Authentication Method to One-time Password, then the operator must sign on using the one-time password generated by the hardware token, even if it is the first sign-on. • If One-time Password is selected and you select another authentication method, then the operator must use the associated user password. If the new authentication method is Local, then the user is prompted to change password. If the authentication method is LDAP, then the operator must sign on with an LDAP password. To modify an operator: 1. Ensure that the operator whose definition that you are modifying is logged out of the system. 2. From the View menu of Security Definition, select Operator. 3. Double-click the operator that you want to modify. 4. If necessary, modify the Full Name field. 5. Move profiles to and from the Available and Selected columns as required. 6. Move units to and from the Available and Selected columns as required. 7. If you are using a UNIX server, then move printers to and from the Available and Selected columns as required. 8. From the Operator menu, select Modify. Note 92 After modifying the operator, the operator becomes Unapproved. The left security officer and right security officer, or operators with the appropriate approval entitlements, must approve the operators again. For information about how to approve modified operators, see "Approving and Enabling Operator Definitions" on page 90. System Management Guide Managing Alliance Access Security 11.11 Listing Operators 11.11.1 About Listing Operators Overview When you select Operator from the View menu of the Security Definition application, all the operators whose details you are entitled to see are listed. Note There may be restrictions on exactly which operator details that you can list, search for, and use other operator-related functions on. This depends on the setting of the Operator: Restrict Functions and Restrict Delegation configuration parameters. See "Restricting Operator Functions" on page 112. The Operator column shows the name that each operator uses to sign on to Alliance Access. The Operator Name column shows the full name of each operator. Each operator has an Approval Status that shows whether they have been given permission to use the system. Approval Status Description Approved The operator is entitled to use the system in the way described in their operator definition Unapproved The operator cannot use the system until they are approved by left security officer and right security officer, or by operators with the appropriate approval entitlements Wait LSO Approval The operator has been approved by the right security officer, but requires approval by either the left security officer or an operator with the Approval Operator entitlement and permission to left-approve Wait RSO Approval The operator has been approved by the left security officer, but requires approval by either the right security officer or an operator with the Approval Operator entitlement and permission to right-approve A new or modified operator definition always requires approval by both security officers, or by operators with the appropriate approval entitlements. The Enable Status column shows if the operator is enabled or disabled. New operators are always disabled until they have been both left and right-approved, at which time they are automatically enabled. The Last Sign-on column shows the date and time that the operator most recently logged on. The Authentication Method column shows which of the following methods is used to authenticate the user: Local, One-time Password, or LDAP. The Application column shows whether the user is an application that connects to Alliance Access. 15 July 2011 93 Alliance Access 7.0.20 11.11.2 Procedure for Listing Operators To list operators that meet certain criteria: 1. From the View menu of the Security Definition application, select Operator. 2. From the Operator menu, select Search. The Operator Search Criteria window appears. 3. Click the Operator tab. From the Approval Status field, select one of the following: Select To see Any All operators, whatever status they have Approved All the approved operators Unapproved All the operators that are not approved Wait LSO Approval All the operators that need approval by the left security officer, or by an operator entitled to left-approve Wait RSO Approval All the operators that need approval by the right security officer, or by an operator entitled to right-approve From the Enable Status field, select one of the following: 94 Select To see Any All operators, whatever status they have Enabled All the enabled operators Disabled All the disabled operators System Management Guide Managing Alliance Access Security Select To see Time Disabled All the operators that are disabled for a fixed period of time rather than indefinitely In the Operator Name field, type an operator name. You can use the following wildcard characters to search for a group of Operator Names: _ to replace one character in a string. For example, type OPER0_ to match "OPER01", "OPER02", "OPER03", and so on % to replace zero or more contiguous characters in a string. For example, type OP%01 to match both "OPERATOR01" and "OPER01" From the Authentication field, select one of the following: 4. 15 July 2011 Select To see Any All operators, whatever authentication method is used Local All the operators who are authenticated by the Local authentication method LDAP All the operators who are authenticated by the LDAP authentication method One-time Password All the operators who are authenticated by the One-time Password authentication method Click the Profiles tab. 95 Alliance Access 7.0.20 From the Profile Assignment field, select one of the following: 5. Select To see Any Profile Matching String Operators who use the profile name entered in the Profile field. The wildcard characters % and _ can be used in the profile name to widen the search so that you can search for a group of names. All Profiles In Selected List Operators who use the profile(s) in the Profiles/Selected column. Profile names can be selected from the Profiles/Available column. If you select several profiles, then Alliance Access only searches for operators who have all your selected profiles. Click the Units tab. From the Unit Assignment field, select one of the following: 6. 96 Select To see Any Unit Matching String Operators who use the unit name entered in the Unit field. The wildcard characters % and _ can be used in the unit name to widen the search so that you can search for a group of names. All Units In Selected List Operators who use the unit(s) in the Units/Selected column. Unit names can be selected from the Units/Available column. If you select several units, then Alliance Access only searches for operators who have all your selected units. Click the Printers tab (only available for UNIX servers). System Management Guide Managing Alliance Access Security The printers used in the search appear in the Printers/Selected column. Printer names can be selected from the Printers/Available column. If you select several printers, then Alliance Access only searches for operators who are entitled to use all your selected Printers. 7. Click Note Search . The operators that meet your search criteria appear within the window. If the security configuration parameter Operator: Restrict Functions is set to Yes, then the search displays operators who meet the search criteria, and who belong to a subset of the units assigned to the signed on operator carrying out the search. For details about the Operator: Restrict Functions parameter, see "Restricting Operator Functions" on page 112. 11.12 Creating Operator and Profile Details Reports Overview If you have permission, then you can generate a file containing full operator and operator profile details. This file can be used as input to a security audit application. 15 July 2011 97 Alliance Access 7.0.20 To generate a full operator and profile details report: 1. Run the Security Definition application. 2. Select Create Op List... from the File menu. The Create Operators/Operator Profiles List window appears. 3. Select the location where the file must be generated from the File on drop-down menu: • Workstation, to create the file in a location of your choice. If you select Workstation, then an additional field called File location appears to allow you to specify the file location. You can either type a path name or click ... to locate a directory. • Server, to create the file in your default report directory specified in the Root path for Report File security configuration parameter. For details about this parameter, see "Security Parameters" on page 102. 4. Click: • OK • Continue if you selected Workstation if you selected Server. 11.13 Disabling Operators Overview The operator definition for an approved and enabled operator can be disabled, so that the operator cannot sign on to Alliance Access. For example, you may decide to disable an operator's definition because the operator is ill or on holiday. You can disable an operator definition until a specific date and time, or disable it indefinitely. You can also automatically disable an operator who has not signed on for a certain period of time (see "Signon Time Limits" in the Security Guide). Whichever method is used to disable the operator definition, you can enable the definition by using the Enable command in the Operator menu. To disable an operator definition: 98 1. From the View menu of Security Definition, select Operator. 2. Click the operator. 3. From the Operator menu, select Disable. 4. Select a Next Sign On Allowed option. System Management Guide Managing Alliance Access Security Select from the following: • On the Following Date, to disable the operator definition until the date, and time that you specify, or until you enable the definition again with an Enable command. • By Enable Command, to disable the operator definition until you enable the definition again with an Enable command. 5. Click OK to disable the operator definition, or Cancel to quit. 11.14 Removing Operators Overview If an operator no longer uses Alliance Access, then you can remove the operator's definition. For example, you can do this if an operator no longer works for your organisation. To remove an operator: 1. From the View menu of Security Definition, select Operator. 2. Click the operator. 3. From the Operator menu, select Remove. 4. Click Note Yes to confirm the removal, or No to stop it. Operators cannot be removed if they are specified in an Alarm Distribution List. First remove the operator from the Alarm Distribution List (see "Configuring Event and Alarm Distribution" on page 171). If the operator is the only operator assigned to that specific list, then you cannot remove this operator. You must first assign another operator to the Distribution List and then remove the first one. When the operator is no longer specified in any Alarm Distribution List, the operator can be removed in the Security Definition application. 11.15 Resetting Operator Passwords Overview If an operator forgets their user password, then the security officers, or operators with the appropriate Approve Operator entitlement, can reset the password. Note The password of an Application operator can only be regenerated by the Security Officers using the Reset User Pwd function in the Security Definition application. To reset an operator password: 15 July 2011 1. Sign on to Alliance Access as left security officer, or as an operator entitled to left-approve. 2. Double-click the Security Definition icon. 3. From the View menu, select Operator. 4. Double-click the operator password that you want to reset. 99 Alliance Access 7.0.20 5. From the Operator menu, select Reset User Pwd. The operator's user password is disabled and they can only sign on once a new password has been generated. Check mark the Display Password box to the right of the Auto Password field. The password (case-sensitive) is displayed. Take note of the password and pass it secretly to the operator for whom the definition is being created. 6. Sign off. 7. Sign on to Alliance Access as right security officer, or as an operator entitled to rightapprove. 8. Double-click the Security Definition icon. 9. Double-click the operator password that you want to reset. Check mark the Display Password box to the right of the Auto Password field. The password (case-sensitive) is displayed. Take note of the password and pass it secretly to the operator for whom the definition is being created. The operator must then sign on using the two halves of the password. The operator then has to follow the same procedure as if they were signing on for the first time. 11.16 Resetting Security Officer Passwords Overview If a security officer (left security officer or right security officer) forgets their password, then the password can only be reset if both the following conditions are met: • the other security officer resets the password. An operator with Approve Operator entitlement cannot do so. • the Password: Reset Peer Officer Pwd security parameter is set to Yes. By default, the Password: Reset Peer Officer Pwd parameter is set to No, which means that the security officers cannot reset each other's password. The security officers can use the Security Definition application to change the value of this and other security parameters. For details, see "Modifying Security Parameters" on page 101. Note If the Password: Reset Peer Officer Pwd parameter is set to No, and a security officer forgets a password, then the security officer's password cannot be reset. Support must be contacted for further instructions. 11.16.1 Resetting the Left Security Officer Password To reset the left security officer password: 100 1. Sign on to Alliance Access as right security officer. 2. Double-click the Security Definition icon. 3. From the Operator menu, select Reset LSO Pwd. The left security officer's password is reset to the eight hexadecimal-character Master Password that SWIFT dispatched to the left security officer at the most recent Alliance Access licensing. Your organisation must have retained the original printed Master Password sent by SWIFT and stored it in a secure place. System Management Guide Managing Alliance Access Security 4. Sign off. 11.16.2 Resetting the Right Security Officer Password To reset the right security officer password: 1. Sign on to Alliance Access as left security officer. 2. Double-click the Security Definition icon. 3. From the Operator menu, select Reset RSO Pwd. The right security officer's password is reset to the eight hexadecimal-character Master Password that SWIFT dispatched to the right security officer at the most recent Alliance Access licensing. Your organisation must have retained the original printed Master Password sent by SWIFT and stored it in a secure place. 4. Sign off. 11.17 User Access Security Overview Alliance Access does not allow a user to sign on and access Alliance Access applications if any of the following apply: • The system password has been changed • The user types the wrong password • The operator definition has been deleted from the system • The user attempts to sign on outside the times specified in the assigned operator profile • The user has not logged in within the maximum time allocated • The operator has not signed on within the sign-on time limits defined within that operator's profile, automatically disabling the operator • Another user is currently signed on at the terminal at which the user is trying to sign on • The operator definition is not approved • The operator definition is disabled. When an operator is refused entry to Alliance Access, a descriptive account of the event is logged in the Event Journal, in the Operator event class. 11.18 Modifying Security Parameters Overview A number of security parameters control system security. Only the security officers (left security officer and right security officer) can modify these parameters, from the Security Definition application. Both security officers must approve any modifications. 15 July 2011 101 Alliance Access 7.0.20 11.18.1 Security Parameters List of security parameters In the Security Definition application, select Configuration from the View menu to see a list by class and name of the modifiable security parameters: Class Parameter Description Alarm Windows only. Path of Script File The full path name of the user-defined script executed on occurrence of an alarm event. It must be: • owned by the Alliance Administrator (AllAdm) • located in a directory accessible by this user For UNIX only: Path of Script File The full path name of the user-defined UNIX shell script executed on occurrence of an alarm event. It must be: • owned by the Alliance Administrator (AllAdm) • located in a directory accessible by this user • compliant with the requirements of the UNIX exec system call regarding the execution of an interpreter file. Backup integrity Backup integrity Specifies the type of digest that is calculated to ensure the integrity of archive backups. Possible values are: • Fast - integrity of the backup is based on a digest covering the metadata • Full - a second digest is added, covering the data in the backup. Default value: Full. Mesg Archive Archive Method Possible values are: • Normal - create the archive (all messages must be completed) • Destructive - do not create archive, all messages must be completed, and are deleted from the database. Default value: Normal. 102 System Management Guide Managing Alliance Access Security Class Parameter Description Message Check authorisation exist Indicates whether the existence of an RMA authorisation is checked during message entry or message modification. Default: Yes. Note: If you have licence option 07:STANDALONE REC, then this parameter indicates whether an RMA check is performed whatever the network is (OTHER included). Default value: No. Message Journalise Msg Text If this parameter is set, then the text block from the message is included in the message event description. A change to this parameter will take effect after the SWIFT Interface component is restarted. Possible values are: • Message Text Journalised • Message Text Not Journalised Default value: Message Text Journalised. Message Message Repair Action Indicates the type of action that is performed by default on the outstanding live messages, that are flagged with possible duplicate emission (PDE), if a database is partially recovered: • Prompted - the user can select an option when the tool is launched • None - the messages are routed as defined • Complete - the messages are completed • Investigate - the messages are routed to the _MP_recovery queue for investigation. This parameter appears when 14:DATABASE RECOVERY or 13:HOSTED DATABASE are licensed. Message MT398 message extraction Specifies whether the SWIFT Interface component performs a proprietary authentication code verification (PAC) on messages embedded in the MT 398. A change to this parameter will take effect after the SWIFT Interface component is restarted. Possible values are: • Off • On Default value: Off. Message Re-activation Scope Setting used to re-activate completed messages to any routing point. Reception Date: • Full - All routing and exit points are displayed • Partial - All exit points are displayed • Restricted - The target re-activation queue is automatically selected: – Text Modification Queue for input messages 15 July 2011 103 Alliance Access 7.0.20 Class Parameter Description – Modification After Reception Queue for output messages. Default value: Full. Message Retrieved Message Extract When set to On, the SWIFT Interface component extracts the contents of MT 021, if output messages, into separate messages. A change to this parameter will take effect after the SWIFT Interface component is restarted. Possible values are: • Off • On Default value: Off. Operator Restrict Functions Specifies whether the operator-related functions (open, print, add, modify, approve, or remove) are restricted. If this parameter is set to No (the default), then these functions are not restricted, and an operator with the appropriate entitlements can search for, open, print, add, modify, approve, or remove operators belonging to any unit. If the parameter is set to Yes, then an operator with the appropriate entitlements can only use these functions on operators who belong to a subset of the same units as the operator carrying out the action. For more information, see "Restricting Operator Functions" on page 112. Possible values are: • Yes • No Default value: No. This parameter does not affect the left security officer and right security officer, who always have unrestricted access to operator functions. Operator Restrict Delegation Indicates whether restrictions may be applied for Operator profiles, Units, and Destinations when an LSO/RSO defines an operator definition. The left security officer and right security officer of a Service Bureau use this feature when creating local security officers. Possible values are: • Yes: a third tab appears in the Security Definition application Operator Profile Details window. Delegation is then possible. In this state, this parameter overrides the Restrict Functions parameter. • No: Delegation is not possible. Default value: No. Operator 104 Software Owner Profile Specifies the operator profile that is assigned as the owner of the software. An operator with that profile can perform specific actions on Alliance Access, such as, exporting configuration data, or querying the database for messages or events. If this parameter is empty or invalid, then the software owner operator is disabled. The servers must be restarted for changes to this parameter to take effect. System Management Guide Managing Alliance Access Security Class Parameter Description Password Illegal Patterns Patterns of characters that are not allowed in passwords. The | symbol must be used to separate each string of characters that is prohibited. For example, the string: @|$|Bob prohibits the use of the following characters in passwords: @ $ Bob Password Master Period Specifies the number of days after which the security officers have to change the Master Passwords. Possible values are: • 0 through 365 Default value: 100. A value of 0 means that the security officers are never forced to change their passwords. Password Max Bad Pwd Maximum number of times that a user can enter incorrect passwords before sign-on is refused. Possible values are: • 0 through 100 Default value: 5. Password Min Pwd Length Minimum length of the user password. Possible values are: • 4 through 20 Default value: 6. Password Nbr Retained Pwd The number of user passwords retained by the system. Each time a user changes a password, the old password is retained until this number is reached. A user cannot create a password that is the same as one that is retained. Possible values are: • 0 through 20 Default value: 10. Password Reset Peer Officer Passwo Allows the left security officer to reset the right security officer's password to the Master Password which was valid at the time of installation, and vice versa. This is useful if a security officer forgets a password. An event is written to the Event Journal each time that a password is reset. The default is No, which means that the security officers cannot reset each other's password. Possible values are: • Yes • No Default value: No. Password 15 July 2011 Sec Officer One Time Pwd Activates the use of one-time passwords for the security officers. If this parameter is set to Yes and a primary authentication server 105 Alliance Access 7.0.20 Class Parameter Description has been configured, then the left security officer and right security officer can use one-time passwords. Possible values are: • Yes • No Default value: No. Password Strong Validation Verifies that password contains a combination of alphabetic and numeric characters, and at least one numeric character. Changes to this parameter become effective at the next password change. Possible values are: • Yes • No Default value: No. Password User Period Number of days after which the user password has to be changed. Possible values are: • 0 through 120 Default value: 30. Reports Root Path for Report File The path name which is the top level of the directory tree where report files are stored. The default location is: • UNIX - $ALLIANCE/usrdata/report • Windows - %ALLIANCE%\usrdata\report RMA Clean up Stale Auth. Specifies the minimum number of days that an authorisation or a query must be kept in the data store before it can be removed. Maximum: 365. Default value: 180. RMA Needs Status Confirmation Controls the explicit request to confirm the rejection of Authorisations to Send, and the revocation of Authorisations to Receive. A change to this parameter takes effect immediately. Default value: Yes. RMA Auto Accept Updates Specifies whether updates received for enabled authorisations to send are automatically accepted. A change to this parameter takes effect immediately. Default value: No. Signoff Timeout Specifies the time (in seconds) after an inactivity timeout before the workstation is automatically signed off. Possible values are: • 0 through 3600 Default value: 1800. If 0 is selected, then the workstation is not signed off automatically. 106 System Management Guide Managing Alliance Access Security Class Parameter Description Signoff WS Session Timeout The number of seconds of inactivity after which Alliance Access cleans up a web-service operator session. Minimum: 1800. Maximum: 5400. Default value: 2700. Signon Multiple The number of concurrent signons allowed for an operator. Possible values are: • 1 through 10 Default value: 1. Signon Timeout Specifies the time (in seconds) that an operator can be inactive at a workstation (while Alliance is running) before having to re-enter a password. Possible values are: • 60 through 28800 Default value: 600. System Authenticate MT971 Defines whether MT 971 messages must be authenticated or not. A change to the parameter is taken into account immediately. Possible values are: • Yes • No Default value: Yes. System Disable Period This parameter specifies the number of days (1 to 999) during which an enabled operator must sign-on. If they do not do so, then they are automatically disabled. Possible values are: • 0 through 999 Default value: 0. If this parameter is set to 0, then operators are not automatically disabled. System RPC Authentication Defines whether the communication between Alliance Access and Alliance Workstation is encrypted. Only when the parameter is set to "Data Integrity" or "Data Confidentiality" can the Alliance Access servers initialise the communication process with SSL enabled. If SSL is enabled, then Alliance Workstation can also use Server Authentication. For more information, see the Alliance Workstation Installation and Administration Guide. This parameter provides additional security checks on client processes that make Remote Procedure Calls (RPC) to server processes. Possible values are: • Off - processes making RPCs are not checked to ensure that they are authenticated. • Process Authentication - processes making RPCs are checked to ensure that they are authenticated. • Data Integrity - in addition to Process Authentication, Alliance calculates a check value based on the character field data in 15 July 2011 107 Alliance Access 7.0.20 Class Parameter Description the RPC call. The check value and the RPC call are passed to the server. The server recalculates the check value from the RPC data, and compares it to the check value that it received. This ensures the integrity of the RPC data. If any changes have been made to the data, then the check values will not match. • Data Confidentiality - in addition to Data Integrity, the following RPC call data is encrypted to ensure confidentiality: – all fields that are currently encrypted in the database (such as the operator password) – all message details that are derived from the message text. Default value: Process Authentication. Alliance must be restarted for changes to this parameter to take effect. If a large number of message templates are assigned to a unit, then using the higher levels of RPC authentication affects the performance of the Message Creation application. When the Data Confidentiality option is used, an operator who belongs to that unit will find that the Message Creation application opens very slowly. If more than 50 message templates are in use, then it is recommended that you use the low speed mode setting, which allows fewer items to be displayed more quickly. At this setting, only 50 records are retrieved each time that a list of items appears. For information about how to set the speed mode, refer to "Setting the Speed Mode" on page 20. Warning The Data Confidentiality mode is CPU-intensive. When selected, it significantly decreases the overall throughput of Alliance Access. This mode is therefore not recommended for highthroughput configurations. System Software Check at Startup Determines whether the system runs the Integrity Verification Tool when Alliance Access is started, to check the integrity of the Alliance Access software. Possible values are: • Yes • No Default value: Yes User Mode Housekeeping User Mode In housekeeping mode, either a Single Operator is allowed to sign on or Multiple Operators are allowed to sign on. Possible values are: • Single • Multiple Default value: Single. Alliance Access must be restarted for changes to this parameter to take effect. 108 System Management Guide Managing Alliance Access Security Class Parameter User Space Root Path for User Space Description The location on the Alliance Access server where the user space directories are created. The default location is: • UNIX - $ALLIANCE/usrdata/userspace • Windows - %ALLIANCE%\usrdata\userspace The directories are associated with operators using the Alliance Web Platform. 11.18.2 Viewing the Approval Status To view the approval status: 1. Start the Security Definition application. 2. From the Configuration menu, select View, then Approval Status. Possible statuses are: • approved • unapproved • wait LSO approval • wait RSO approval. 11.18.3 Modifying Security Parameters Overview Both the left security officer and the right security officer must be involved in the modification of security parameters. To modify a security parameter: 15 July 2011 1. Sign on to Alliance Access as left security officer. 2. Double-click the Security Definition icon. 3. Select Configuration from the View menu. The security parameters are listed by class and name. 4. Double-click the parameter that you want to modify. The Security Parameter Details window appears. 109 Alliance Access 7.0.20 For a description of the fields displayed in this window, see "Security Parameter Details Window" on page 110. 5. Type the value that you want the parameter to have once it is approved in the Future Value field, or select the value from the drop-down list (some parameters have pre-defined options). 6. Select Modify from the Configuration menu. 7. Select Approve from the Configuration menu. 8. Sign off. 9. Sign on to Alliance Access as right security officer. 10. Select the modified parameter. 11. Select Approve from the Configuration menu. 12. Select Approval Status from the View menu and confirm that the status of the parameter has changed to Approved. 11.19 Security Parameter Details Window Description The Security Parameter Details window appears after selecting a parameter from the list in the Security Definition main window and selecting Open or Modify from the Configuration menu. The window contains a single panel displaying the details of the selected security configuration parameter. 110 System Management Guide Managing Alliance Access Security Example of Security Parameter Details window Field descriptions Class The category to which the parameter belongs (for example, "Password"). Parameter The name of the parameter. Future Value The value that you want the parameter to have when it has been approved by both security officers. Current Value The current value of the parameter. Approval Status Indicates whether a modification of the parameter has been approved. Default Value The default value of the parameter. This value is pre-defined and applies when Alliance Access is first installed. This value applies unless you modify the Current Value. Minimum Value The minimum value allowed for the parameter. This is only applicable to numeric values. Maximum Value The maximum value allowed for the parameter. This is only applicable to numeric values. Description A description of what the parameter does. 15 July 2011 111 Alliance Access 7.0.20 11.20 Restricting Operator Functions Overview Operators are divided into sub-groups by assigning the operators to different units. It can be useful to restrict operators so that they can only carry out operator-related functions on operators who belong to the same units. If the security configuration parameter Operator: Restrict Functions is set to Yes, then the following restrictions apply to those operators who have the entitlements to carry out operatorrelated functions: • an operator can only assign a subset of the units assigned to himself, to another operator. • an operator A can only display information and use operator-related functions on another operator B, if the set of units assigned to operator B is a subset of the units assigned to the operator A. Operator A can use the following functions: – list operator – open/print operator – approve operator – enable operator – disable operator – add operator – modify operator – delete operator – search operator – reset password (if the operator has the Approve Operator entitlement). For example, if operator Marc belongs to units A, B and C, and operator Luc belongs to units C and D, neither Marc or Luc can display each other's operator details. Operator Dirk, who belongs to units A, B, C, and D, can display the operator details for both Marc and Luc and use operator-related functions on them. However, neither Marc or Luc can display Dirk's operator details. Note When the parameter Restrict Delegation is set to Yes, any profile assignments made for units using the Security Definition application take precedence. This does not affect the left security officer and right security officer. The Operator: Restrict Functions parameter does not affect the left security officer and right security officer, who always have unrestricted access to operator functions. 112 System Management Guide Managing Alliance Access Security 11.21 Configuring Authentication Servers 11.21.1 Configuring One-Time Password Servers Overview If you use one-time passwords, then you must configure an authentication server before you can use such passwords. This task is performed from the Security Definition application and requires proper operator permissions. Alliance Access requires the following configuration information to be able to reach the authentication server: • host name of the authentication servers (Primary and Secondary) • port number to reach the authentication servers (Primary and Secondary) • a secret key used by the protocol (Primary and Secondary, the secret key values are saved encrypted within Alliance Access) • local port number (the port number local to the Alliance Access host). This configuration is necessary to support the protocol used between Alliance Access and the supported authentication server. The configuration must be done before using the authentication server. Password compliancy rules The Left and Right parts of the secret each consist of 16 characters. These characters must be US-ASCII encoded characters 32 through 126. Each part must also comply with the following complexity rules: • it must contain at least one upper-case and one lower-case alphabetic character • it must contain at least one number • a character cannot be repeated more than half of the length minus one. To configure the authentication server: 15 July 2011 1. Run the Security Definition application. 2. From the File menu, select Configure Authentication Servers and then One-Time Password.... The Configure One-Time Password Servers window appears, showing the current configuration details. To modify them, complete the Future fields as described in the following steps. Both the left security officer and the right security officer must approve changes to the current configuration. 113 Alliance Access 7.0.20 Note 3. When you select Configure Authentication Servers and One-Time Password... for the first time, that is, after installing or upgrading Alliance Access, the Current and Future fields are empty and the Current Mode field displays Do not Use Authentication Server. In the Future Mode field, select whether an authentication server must be used. Select: • Use Authentication Server if you want to use one-time passwords • Do not use Authentication Server if you do not want to use one-time passwords. If you select Use Authentication Server, you must complete the fields as described in the next steps. Note 114 You must complete the fields for the Primary Authentication Server before you can start using one-time passwords. 4. In the Future Local Port Number field, specify the port number to reach the primary authentication server. Enter a value between 1024 and 65535. 5. In the Primary Authentication Server area, enter the host name of the primary authentication server in the Hostname field. 6. In the Port Number field, specify the port number to reach the primary authentication server. Enter a value between 1024 and 65535. System Management Guide Managing Alliance Access Security 7. In the Left Secret field, enter the left part of the secret of the primary authentication server. It consists of 16 characters. Note Depending on your permissions, the secrets are either displayed in clear or substituted by '*'. Secrets must be stored encrypted. They have a lifetime of two years, after which they expire. The following recommendations must be observed for the secrets: • If you define two authentication servers, then the two secrets for both servers must be different. • The secret keys must be renewed every 3 to 6 months. • An implementation of network access control (firewalls, ACL's) or segregation of message flow (main and management flow) can be considered. 8. Click Save to save your changes. You can only save your changes if at least the Hostname and the Port Number fields contain a value. The Configuration Status field displays the current approval status, that is, Unapproved. 9. Click Approve to approve the changes. The status changes to Waiting RSO Approval. The right security officer must now sign on and approve the changes. Note Approve is only available to the left security officer and right security officer. 10. In the Right Secret field, enter the right part of the secret of the primary authentication server. It consists of 16 characters. 11. Click Approve to approve the changes. The status changes to Approved and the Future field settings become Current. 12. Check the Use Secondary Authentication Server box if you want to define a secondary authentication server. This is optional. If you check this box, then complete the fields that appear as described in the previous steps. When the primary server cannot be connected to or if the connection is lost, a switch from the primary authentication server to the secondary one occurs. Note The left security officer and right security officer can clear the Future field settings by clicking Reset . This option is available when the Configuration Status field displays the following values: • Unapproved • Waiting LSO Approval • Waiting RSO Approval 15 July 2011 115 Alliance Access 7.0.20 11.21.2 Configuring LDAP Authentication 11.21.2.1 Configuring LDAP Servers Overview You can configure LDAP repositories for the authentication (user name and password) of users. This task is performed from the Security Definition application and requires proper operator permissions. The Primary LDAP server settings must be completed to use an LDAP server. A Secondary LDAP server may optionally be configured. Alliance Access requires the following configuration information to reach the LDAP server: • host name of the LDAP servers • port number to reach the LDAP servers • whether the connection to the LDAP server must be secured • optionally, the user DN and password used to connect to the LDAP server: not used if the LDAP server supports anonymous access. Moreover, configuration information is also required to access the user information related to a particular LDAP entry. To configure an LDAP server: 116 1. Run the Security Definition application. 2. From the File menu, select Configure Authentication Servers and then LDAP.... The Configure LDAP Servers window appears, showing the current configuration details. To modify them, complete the Future fields as described in the following steps. Both the left security officer and the right security officer, or two users with the Approve LDAP function, must approve changes to the current configuration. System Management Guide Managing Alliance Access Security Note 3. When you select Configure Authentication Servers and LDAP... for the first time, that is, after installing or upgrading Alliance Access, the Current and Future fields are empty and the Current Mode field displays Do not use LDAP Server. In the Future Mode field, select whether an LDAP server must be used. Select: • Use LDAP Server if you want to use LDAP authentication. If you select Use LDAP Server, then you must complete the fields as described in the next steps. Check the Use Secondary LDAP Server box if you want to define a secondary LDAP server. Note You must complete the fields for the Primary LDAP Server and approve this configuration before you can start using LDAP authentication. • Do not use LDAP Server if you do not want to use LDAP authentication. 4. Complete the Primary LDAP Server tab as follows: • Connection Parameters: – In Host Name, you must specify the host name of the primary LDAP server. – In Port Number, specify the port number to reach the primary LDAP server. – Select Connection Security if you want to secure the connection to the LDAP server. – In Connect DN and Connect Password, specify the user DN (250 characters maximum) and password (100 characters maximum) to connect to the LDAP server. These two fields are optional, as the LDAP server may support anonymous access. • User Parameters: – In DN Entry Point in User Directory, specify the DN of the entry point in the user directory. This field can contain 250 characters maximum. In the LDAP search request, Alliance Access specifies that the whole subtree must be searched, starting from the DN specified in DN Entry Point. – In Object Class Name of User Node, optionally specify the type or class of the user nodes within the directory. This is useful if there are different types of nodes in the directory (that is, not only users). This field can contain 32 characters maximum. – In User Name Attribute, specify the name of the attribute containing the user name that is used during the logon operation. This field can contain 32 characters maximum. 5. Click Save to save your changes. You can only save your changes if Hostname, Port Number, DN Entry Point in User Directory, and User Name Attribute contain a value. The Configuration Status field displays the current approval status, that is, Unapproved. 6. 15 July 2011 Click Approve to approve the changes. 117 Alliance Access 7.0.20 The status changes to Waiting RSO Approval or Waiting LSO Approval. This depends on whether the user currently signed on has the Approve Left part or the Approve Right part permission. If the status is: • Waiting LSO Approval, then the user with the Approve Left part permission must sign on now and approve the changes • Waiting RSO Approval, then the user with the Approve Right part permission must sign on now and approve the changes. Note Approve is only available if your operator profile contains the Approve LDAP function. 7. Click Approve to approve the changes. The status changes to Approved and the Future field settings become Current. 8. Check the Use Secondary LDAP Server box if you want to define a secondary LDAP server. This is optional. If you check this box, complete the fields that appear as described in the previous steps. When the primary server cannot be connected to or if the connection is lost, a switch from the primary server to the secondary one occurs. Note The left security officer and right security officer, or users with the Approve LDAP function, can clear the Future field settings by clicking Reset . This option is available when the Configuration Status field displays the following values: • Unapproved • Waiting LSO Approval • Waiting RSO Approval 11.21.2.2 Securing an LDAP Connection Introduction You can use SSL to secure the connection to an LDAP authentication server. The LDAP server must have SSL support enabled. The SSL certificate installed on the LDAP server can be either a self-signed certificate or a certificate signed by a SWIFTNet Certification Authority. The keystore that LDAP uses on Alliance Access must trust either the self-signed SSL certificate or the SWIFTNet Certification Authority certificate. Note You must restart the Alliance server after adding the certificate to the keystore. To add a certificate, perform the applicable procedure that follows. Procedure on Windows 118 1. Log on to Alliance Access as Alliance Administrator. 2. Open a DOS command prompt. 3. Enter mmc to launch the Microsoft Management Console application. System Management Guide Managing Alliance Access Security The Microsoft Management Console window appears. 4. Use File > Open to open the file <WINDOWS>/system32/certmgr.msc, where you replace <WINDOWS> with the path to the Windows directory on the Alliance Access server. The Certificates - Current User window appears. 5. Select the Trusted Root Certification Authorities > Certificates store. 6. Select Action > All Tasks > Import. The Certificate Import Wizard appears. 7. Follow the instructions in the Certificate Import Wizard to import either the self-signed SSL certificate or the SWIFTNet Certification Authority certificate in the Trusted Root Certification Authorities certificate store. A Security Warning message appears. 8. Click Yes . A Certificate Import Wizard message appears that confirms the successful import of the certificate. 9. Click OK . 10. Close the Certificates - Current User window. A Microsoft Management Console dialog box appears. 11. Click Yes . The Certificates - Current User window closes. Procedure on AIX 1. Log on to Alliance Access as Alliance Administrator. 2. Launch the gsk7ikm graphical application. Running the gsk7ikm graphical application requires the JAVA_HOME environment variable to be defined. Set the JAVA_HOME environment variable in an Alliance Access Xterm window by typing export JAVA_HOME=<the java path>. Usually, <the java path> looks like /usr/java14. If you use an X-Window-based tool to connect remotely to theAlliance Access server, make sure the DISPLAY environment variable is set to the display of your workstation. Also, if 15 July 2011 119 Alliance Access 7.0.20 there is a firewall in use between Alliance Access and your workstation, make sure you configure the firewall rules to allow X-Window communication. 3. Create a new keystore in the $ALLIANCE/data/ldap directory. Select CMS for Key database type and enter key.kdb in the File Name field. The Password Prompt appears. 4. Type a password and a confirmation of the password, and select the Stash the password to a file option. 5. Click 6. Add either the self-signed SSL certificate or the SWIFTNet Certification Authority certificate to the keystore. OK . Procedure on Oracle Solaris 1. Log on to Alliance Access as Alliance Administrator. 2. Open a Korn shell. 3. Use the certutil command-line application to create a new keystore in the $ALLIANCE/data/ldap directory: /usr/sfw/bin/certutil -N -d $ALLIANCE/data/ldap 4. Add either the self-signed SSL certificate or the SWIFTNet Certification Authority certificate to the keystore. /usr/sfw/bin/certutil -A -n "<certificate_alias>" -i <certificate_file> -a -t "C,C,C" -d $ALLIANCE/data/ldap Replace <certificate_alias> with the name of the certificate. Replace <certificate_file> with the path and filename of the certificate. • To list the certificates in the keystore, enter: /usr/sfw/bin/certutil -L -d $ALLIANCE/data/ldap • To delete a certificate from the keystore, enter: /usr/sfw/bin/certutil -D -n "<certificate_alias>" -d $ALLIANCE/data/ ldap 120 System Management Guide SWIFTNet Security 12 SWIFTNet Security Overview This section describes how MT and MX messages are authenticated. 12.1 For MT Messaging Description MT messages are wrapped into a SWIFTNet envelope. This envelope is signed using a business certificate of a Distinguished Name (DN) that has the fin role in the swift.fin service assigned. In Alliance Access, this Distinguished Name is called the Authoriser DN. SWIFTNet Message (Authoriser DN) Sender/Receiver name Service Name = swift.fin Signature (PKI) MT103 Sender BIC Receiver BIC D0540083 MT Message (unchanged) When an Authoriser DN is created from within Alliance Access, the fin role is automatically assigned to this DN. If you create your DNs from another Alliance interface, such as Alliance Gateway or Alliance WebStation, then the fin role must be assigned when the DN is defined. On Alliance Access, an Authoriser DN is associated to a SWIFTNet connection that must be assigned to a logical terminal. When the logical terminal is assigned to a SWIFTNet connection the selected Authoriser certificate for that connection is used for the signature of the SWIFTNet envelope. Note Each BIC8 requires its own Authoriser DN. On Alliance Access, you can also have multiple Authoriser DNs on your system at any time. Each DN can be assigned to one or more logical terminals. For example, Authoriser DN1 can be assigned to logical terminal A and Authoriser DN2 can be assigned logical terminal B. 15 July 2011 121 Alliance Access 7.0.20 12.2 For MX Messaging Description MX messages are wrapped into a SWIFTNet envelope. This envelope is signed using a business certificate of a Distinguished Name (DN) that has the appropriate role in the SWIFTNet Business service (for example, swift.if.ia) assigned. In Alliance Access, this Distinguished Name is called the Authoriser DN. SWIFTNet Message (Authoriser DN) ifds.001.001.01 D0540084 MX Message Sender/Receiver name Service Name = "SWIFTNet Business" Signature (PKI) When an Authoriser DN is created from within Alliance Access, the fin role is automatically assigned to this DN. Therefore, you must create or assign the appropriate role and SWIFTNet Business service for MX messaging to your DNs from the Alliance Gateway or Alliance WebStation. On Alliance Access, this Authoriser DN must then be adopted on a SWIFTNet connection which is then assigned to SWIFTNet emission and reception profiles. When the emission and reception profiles are assigned to a SWIFTNet connection, the selected Authoriser certificate for that connection is used for the signature of the SWIFTNet envelope. Alliance Access uses the certificate of the Responder DN (BIC8 match) to sign responses on incoming MX messages. It is therefore required to Adopt from the Alliance Gateway system onto your Alliance Access system, the DNs matching the BIC8 of all possible Responder DNs for which MX messages can be received. The same Authoriser DN can be assigned to different profiles. You can also have multiple Authoriser DNs on your system at any time. In this case, each DN can be assigned to one or more profiles. For example, Authoriser DN1 can be assigned to emission profile A and Authoriser DN2 can be assigned to emission profile B. 122 System Management Guide Defining Printers (UNIX only) 13 Defining Printers (UNIX only) Introduction This section contains instructions for defining printers using the System Management application. Printers must be defined before they can be used by local applications. 13.1 Viewing Existing Printer Details To view the details of an existing printer: 1. Run the System Management application. 2. If the Device list pane is not shown, select Device from the View menu. 3. Double-click the printer that you want to view in the Device list pane. The Device Details window appears. For a description of the fields displayed in this window, see "Device Details Window (UNIX only)" on page 123. 13.2 Device Details Window (UNIX only) Description Operators can use the Device Details window to display, modify, or define a printer. The Device Details window appears by selecting a printer in the Device list pane and selecting New As or Open from the Device menu. 15 July 2011 123 Alliance Access 7.0.20 Example Field descriptions Device Name The name of the printer. Device Type Displays the type of device. This can only be a printer. Description Displays the text description of the device, for example, "Printer located in Supervisor's office". Bold Emulation Specifies how bold characters are printed. Lines/page Displays the number of lines per page for the printer. Column Displays the number of characters per line for printer devices. 13.3 Defining New Printer To define a new device: 1. Run the System Management application. 2. If the Device list pane is not shown, then select Device from the View menu. 3. Select one of the following from the Device menu: • New to define a new printer • New As with an existing printer highlighted in the Device list pane, to define a new printer based on an existing one. The Device Details window appears. 124 System Management Guide Defining Printers (UNIX only) For a description of the fields displayed in this window, see "Device Details Window (UNIX only)" on page 123. 4. Enter the name of the printer queue. 5. Type a text description of the new printer in the Description field. 6. Specify how bold characters are printed in the Bold/ Emulation field. The choices are: • Character Overstrike • Line Overstrike • Disable Bold • HP PCL Compatible • DEC LN03 Compatible • IBM/EPSON Matrix. 7. Specify the number of lines per page in the Lines/page field. 8. Specify the number of characters per line in the Column field. 9. From the Device menu, select Add to connect the new printer. The Device main window is automatically refreshed and displays the details of the new printer. Note 15 July 2011 Once you have defined a printer, it must be enabled under UNIX. 125 Alliance Access 7.0.20 14 Installing Application Services Profiles 14.1 About Application Service Profiles Application Service Profile An Application Service Profile is a structured set of parameters that messaging interfaces and applications use to send and receive traffic correctly on a particular SWIFTNet service. These parameters trigger the usage of features within SWIFTNet or describe what a messaging interface must do with traffic sent or received. The Application Service Profile parameters determine how Alliance Access handles these features. The following parameters are available per service: • RMA-related parameters • End-to-end signing required and what format the signature can have • Non-repudiation signing required • Store-and-forward usage • SWIFTNet Copy parameters • HeaderInfo element required and usage of this element for the service Application Service Profile package SWIFT provides the Application Service Profiles (and also the FIN Copy Profiles) to the customer in the form of an Application Service Profile package. You can download the Application Service Profile package from www.swift.com > Support > Resources > Download Centre. The package is a ZIP file that contains all the Application Service Profiles and all the FIN Copy Profiles, and contains the following types of files: • ApplProf.dig, which contains the digest of each file contained in the ASP package • The XML schema definitions (ApplProfDigest.xsd, ServiceProfile.xsd, FINCopyServiceProfile.xsd) • The Application Service Profiles for SWIFTNet services, <service>_<YYYY-MM-DDTHHMMSS>.spd • The FINCopy Profile files, Live|TT<service>_[CID]_<YYYY-MMDDTHHMMSS>.fcp FINCopy Profiles are installed one by one. Removal of Application Service Profiles You cannot remove Application Service Profiles after they are installed. If an incorrect package was installed, then a new installation of the correct ASP package must be performed. RMA traffic filtering After installing the Application Services Profiles package, an operator with appropriate permissions can hide activate or deactivate the RMA Traffic Filtering options. To do this, you must use the Alliance Access Configuration package on the Alliance Web Platform. 126 System Management Guide Installing Application Services Profiles For more information about traffic filtering using RMA, see the RMA Service 7.0 Service Description. 14.2 Install an Application Service Profile Introduction The installation installs all the Application Service Profiles and FIN Copy Profiles that included in the package. If the publication date of the ASP package that you are about to install is older than the package that is installed, a warning is given. Note You cannot schedule the installation of Application Service Profiles. You can also install an ASP package through the GUI, using the Alliance Access Configuration Package on Web Platform. The installation can be done in either Housekeeping or Operational mode. Removal of Application Service Profiles You cannot remove Application Service Profiles once they are installed. If an incorrect ASP was installed, then a new installation of the correct ASP package must be performed. Procedure 1. Download the ASP package from www.swift.com to a dedicated directory. 2. Log on to the machine where Alliance Access is installed. 3. Run the Installation application and open a Command Prompt window. From the System Administration application, select Xterm from the OS Configuration menu. 15 July 2011 4. Navigate to the bin directory, one level below the directory where you installed Alliance Access. 5. Run the saa_manageasp command. For details, see "saa_manageasp" in the Installation and Administration Guide. 127 Alliance Access 7.0.20 15 Defining SWIFTNet Profiles Introduction To exchange MX or FileAct messages by means of SWIFTNet, you must define, enable, and activate emission and reception profiles for the SWIFTNet interface. This is achieved using the SWIFTNet Interface application. 15.1 Set up SWIFTNet Profiles Introduction The SWIFTNet Interface application allows you to manage the InterAct and FileAct traffic. Message flow is controlled using emission profiles for outgoing messages and reception profiles for incoming messages. For each profile defined, a SWIFTNet connection must also be assigned. Profiles must be enabled and activated to be ready for use. You can configure schedules to activate and deactivate the profiles automatically. An active emission profile means that Alliance Access starts checking whether messages are available for sending over SWIFTNet. Alliance Access establishes a connection with SWIFT only if there is one or more messages waiting to be sent. For a store-and-forward reception profile, Alliance Access tries to acquire the queue as soon as the reception profile is activated. If Alliance Access fails to acquire the queue, then the reception profile becomes inactive. FIN Test and Training A licensed live BIC8 that will be used to sign all authorisation messages for FIN Test and Training must have a corresponding SWIFTNet Emission profile and Reception profile. That licensed BIC is referred to as the Signing BIC for Test and Training. 15.1.1 Defining Emission Profiles To define an emission profile: 128 1. Run the SWIFTNet Interface application. 2. If not already displayed, then select Emission Profile from the View menu. The Emission Profile window appears, displaying the list of defined emission profiles. 3. Select New from the Emission Profile menu, or to define one based on an existing emission profile, select the required profile and then New As from the Emission Profile menu. The Emission Profile Details window appears. System Management Guide Defining SWIFTNet Profiles 4. Enter the details of the emission profile. For details, see "Emission Profile Details - Profile Details Tab" on page 129. Note 5. When you specify the service in the Service Name field, the values in the fields are initialised based on the Application Service Profile associated to this service. When you have entered all the required details for the emission profile, select Add from the Emission Profile menu. The new profile now appears in the list of profiles in the Emission Profile View window. To modify an emission profile, select the emission profile and then Open from the Emission Profile menu. You can then change the required fields. Select Modify from the Emission Profile menu to save your modifications. To remove an emission profile, select the emission profile and then Remove from the Emission Profile menu. You are asked to confirm the removal. Click Yes to complete the process. Note To modify or remove an emission profile, the profile must be in the Disabled state. 15.1.2 Emission Profile Details - Profile Details Tab Description The Emission Profile Details window - Profile Details tab shows the parameters for the emission profile. You can define or modify a SWIFTNet profile through this tab. 15 July 2011 129 Alliance Access 7.0.20 Example The following is an example of a SWIFTNet Emission Profile, for the live Relationship Management Service: Field descriptions Profile Name Name of the emission profile. This is the identifier of the profile and cannot be modified after creation. The profile name can be up to 20 alphanumeric characters. No spaces are allowed in the name. Profile Status A read-only field which shows the current status of the profile. Service Name Code for the SWIFTNet service that you are using. The code and associated Requestor DN (see the next field) are used as the basic selection criteria for emission for this profile. This information cannot be modified after profile has been created. Messaging Service You can select InterAct (default), FileAct, or Both. Requestor DN Requestor DN you are using for the SWIFTNet Service selected. This information cannot be modified after the profile has been created. Delivery Mode SWIFTNet delivery mode for the emission profile. This can be Real-time (default) or Store-and-forward. The selection must match the SWIFTNet Service characteristics as provisioned centrally. Use Input Channel This option is available only if the Delivery Mode is Store-and-forward. Input Channel This field is only available if the Delivery Mode is Store-and-forward and Use Input Channel is selected. 130 System Management Guide Defining SWIFTNet Profiles The list of input channel names contains all the input channels available in the database. Window Size The window size used for the emission. This must be in the range 1 to 10 (default 5). This field is not available if the Use Input Channel option is selected. Retry Limit The number of retries for each message (retransmission after emission failure). When the retry limit is reached, the message is routed with a Transmission Failure result. The value must be in the range 0 to 5 (default 2). Signing Required Messages sent using this profile must be signed, unless specified explicitly in the message. Select the check box to enable. If the check box is enabled, then you can select whether to sign MX messages using the Crypto element or the Signature element. Note The InterAct messages that relate to relationship management authorisations are always signed. Non-Repudiation Required Non-repudiation is required for messages sent using this profile, when specified explicitly in the message. Select the check box to enable. The Service Name must be configured with NR Optional or NR Mandated, otherwise the message is rejected. If non-repudiation is required then messages must also be signed. When the Non-Repudiation Required box is selected, the Signing Required box is automatically selected. Note The InterAct messages that relate to relationship management authorisations always require non-repudiation. Delivery Notification Queue Name of the store-and-forward queue that must be used to store store-and-forward delivery notifications (failed delivery notifications and optional successful delivery notifications). Queue names can be up to 30 characters long. This field is only visible if Delivery Mode is Store-and-forward. Delivery Notification Required In Real-time mode, this option is available for files sent using the FileAct or Both Messaging Services. In store-and-forward mode, this option is always available. Select the check box to enable (default is delivery notification not required). Delivery Notification Responder DN Specifies to which Distinguished Name the delivery notification must be sent. If not specified, then the delivery notification is sent to the RequestorDN. This field is only visible if Delivery Notification Required is selected for real-time Delivery Mode. Delivery Notification Request Type Specifies the request type to use when sending the delivery notification. 15 July 2011 131 Alliance Access 7.0.20 This field is only visible if Delivery Notification Required is selected for real-time Delivery Mode. 15.1.3 Defining Reception Profiles To define a reception profile: 1. Run the SWIFTNet Interface application. 2. If not already displayed, then select Reception Profile from the View menu. The Reception Profile window appears, displaying the list of defined reception profiles. 3. Select New from the Reception Profile menu, or to define one based on an existing reception profile, select the required profile then New As from the Reception Profile menu. The Reception Profile Details window appears. 4. Enter the details of the reception profile. For details, see "Reception Profile Details - Profile Details Tab" on page 133. A read only Profile Status field is also displayed which indicates the current status of the profile. 5. When you have entered all the required details for the reception profile, select Add from the Reception Profile menu. The new profile now appears in the list of profiles in the Reception Profile View window. To modify a reception profile, select the reception profile and then Open from the Reception Profile menu. You can then change the required fields. Select Modify from the Reception Profile menu to save your modifications. To remove a reception profile, select the reception profile and then Remove from the Reception Profile menu. You are asked to confirm the removal. Click Yes to complete the process. 132 System Management Guide Defining SWIFTNet Profiles Note To modify or remove a reception profile, the profile must be in the Disabled state. 15.1.4 Reception Profile Details - Profile Details Tab Description The Reception Profile Details window - Profile Details tab shows the parameters for the reception profile. You can define or modify a profile through this tab. Example The following is an example of a SWIFTNet Reception Profile, for the live Relationship Management Service: Field descriptions Profile Name Name of the reception profile. This is the identifier of the profile and cannot be modified after creation. The profile name can be up to 20 alphanumeric characters. No spaces are allowed in the name. Profile Status A read-only field which shows the current status of the profile. Delivery Mode SWIFTNet delivery mode for the reception profile. This can be Real-time or Store-and-forward. The selection must match the SWIFTNet Service characteristics as provisioned centrally. Important Do not change the delivery mode of the Reception profiles for the Relationship Management service. Queue Name Name of the store-and-forward queue that used with this reception profile. Queue names can be up to 30 characters. Note that this field is only visible if Delivery Mode is Store-and-forward. Subset and Order Allows you to select the type of traffic (maximum 6 subsets), and the order that the traffic is delivered. The default order is: System, InterAct, and then FileAct. 15 July 2011 133 Alliance Access 7.0.20 Note To receive delivery notifications, ensure that the Interact and System subsets are selected. For a description of the different types of delivery notifications, see the SWIFTNet Messaging Operations Guide. Use Specific Output Channel This option is available only if the Delivery Mode is Store-and-forward. Output Channel This field is only available if the Delivery Mode is Store-and-forward and Use Specific Output Channel is selected. The list of input channel names contains all the input channels available in the database. Use Specific Window Size Checking this allows a specific window size to be set. If you check this, then the Window Size field appears. Note that this field is only visible if Delivery Mode is Store-and-forward. Window Size You can set the window size up to a maximum of 100 (default is 10). Note that this field is only visible if Delivery Mode is Store-and-forward, and you have checked Use Specific Window Size. 15.2 Assigning SWIFTNet Connections to SWIFTNet Profiles Introduction For each emission or reception profile, you must assign a SWIFTNet connection. For the selected SWIFTNet connection, you can optionally assign a specific Authoriser DN. If you do not select an Authoriser DN, then Alliance Gateway determines the Authoriser DN to be used. Message partners with relaxed certificates If a connection to an Alliance Gateway is defined in Alliance Access with no Authoriser DN specified for the connection, then Alliance Gateway selects any certificate that is defined for the destination in the Alliance Gateway message partner. For more information, see "Certificates used if no Authoriser DN is specified" on page 135. To prevent Alliance Gateway from using a non-FIN certificate for FIN messages, and vice versa, the Alliance Gateway message partners must be configured with the correct type of certificate, as follows: Alliance Gateway message partner 134 Contain certificates which are valid for fin_<instance> FIN, which are associated with logical terminal connections for MT messages sni_<instance> non-FIN, which are associated with SWIFTNet Emission and Reception Profiles, for non-FIN messages System Management Guide Defining SWIFTNet Profiles Authoriser DN for logical terminals The following are requirements for the authoriser DN for logical terminals: • If the logical terminal belongs to a live destination, then the certificate of the authoriser DN must be a business certificate and must be stored on a Hardware Security Module (HSM) with policy ID 1.3.21.6.2. • If the logical terminal belongs to a Test and Training destination, then the certificate of the authoriser DN can be: – a business certificate – a Lite certificate This certificate can be stored in an HSM or on disk. Certificates used if no Authoriser DN is specified If you do not select an Authoriser DN in the following profiles, then Alliance Gateway determines which certificate to use to sign incoming and outgoing traffic: • store-and-forward emission profile • store-and-forward reception profile • real-time emission profile Note It is not possible to specify the Authoriser DN for real-time reception profiles. Alliance Gateway determines certificate to use to sign real-time delivery notifications. If required, Alliance Gateway selects the certificate from the list of related Gateway message partner as follows: 1. Alliance Gateway selects the first DN certificate from the list of related Gateway message partner that matches the level-2 DN (BIC8). 2. Alliance Gateway only selects a certificate for which a security context can be created (for example, the certificate is not revoked or expired). Important Ensure that the certificate that Alliance Gateway selects based on the criteria above has the proper RBAC roles for the type of traffic. 15.2.1 Assigning a Connection to an Emission Profile To assign a SWIFTNet connection to an emission profile: 1. Select the emission profile that you want to assign to a connection from the Emission Profile View list of the SWIFTNet Interface application. If the Emission Profile View window is not shown, then select Emission Profile from the View menu. 2. Select Open from the Emission Profile menu. The Emission Profile Details window opens. 3. Click the Connection Details tab. A list of available SWIFTNet connections appears. 15 July 2011 135 Alliance Access 7.0.20 4. Select the SWIFTNet connection that you want to set up for this emission profile and then select Assign Connection from the Emission Profile menu. The Gateway Connection Details dialog box appears. 5. Select the required connection from the Connection Name field. You must define at least one connection before the emission profile can be enabled. If the Delivery Mode is Store-and-forward, then four connections can be defined. 6. Optionally select Use specific Authoriser DN and enter an Authoriser DN in the Authoriser DN field. The value that you specify must comply with the DN format described in the SWIFTNet Naming and Addressing Guide. If you do not select this option, then Alliance Gateway determines the Authoriser DN to be used. The Authoriser DN must belong to the same institution as the Requestor DN (that is, the BIC8 in both DNs must be the same). Note 7. Click OK . You are prompted to confirm your choice. 8. Click OK to complete the process. The selected SWIFTNet connection is now available to this profile. 15.2.2 Emission Profile Details - Connection Details Tab Description The Connection Details tab is used to select the required SWIFTNet connection. 136 System Management Guide Defining SWIFTNet Profiles Example of Emission Profile Details - Connection Details tab Field descriptions Sequence Number (1 to 4) that indicates the order in which the connections are used when connecting to SWIFTNet, or in case of failure. You must define at least one connection before the emission profile can be enabled. Conn Name Name of the SWIFTNet connection. Authoriser DN Authoriser DN associated with this connection. 15.2.3 Assigning a Connection to a Reception Profile To assign a SWIFTNet connection to a reception profile: 1. Select the reception profile that you want to assign to a connection from the Reception Profile View list of the SWIFTNet Interface application. If the Reception Profile View window is not shown, then select Reception Profile from the View menu. 2. Select Open from the Reception Profile menu. The Reception Profile Details window opens. 3. Click the Connection Details tab. A list of available SWIFTNet connections appears. 15 July 2011 137 Alliance Access 7.0.20 4. Select the SWIFTNet connection that you want to set up for this reception profile and then select Assign Connection from the Reception Profile menu. The Gateway Connection Details dialog box appears. 5. Select the required connection from the Connection Name field. You must define at least one connection before the reception profile can be enabled. If the Delivery Mode is Store-and-forward, then four connections can be defined. If the Delivery Mode is Real-time, then only one connection can be defined. If you change the Delivery Mode of a reception profile from Store-and-forward to Realtime, then only the connection with sequence 1 remains. The other connections are removed. 6. Optionally select Use specific Authoriser DN and enter an Authoriser DN in the Authoriser DN field. The value that you specify must comply with the DN format described in the SWIFTNet Naming and Addressing Guide. If you do not select this option, then Alliance Gateway determines the Authoriser DN to be used. Note 7. Click If the Delivery Mode is Store-and-forward, then the Authoriser DN must have been granted access to the queue with name Queue Name from an external RBAC application. OK . You are prompted to confirm your choice. 8. 138 Click OK to complete the process. The selected SWIFTNet connection is now available to this profile. System Management Guide Defining SWIFTNet Profiles 15.2.4 Reception Profile Details - Connection Details Tab Description The Connection Details tab is used to select the required SWIFTNet connection. Example of Reception Profile Details - Connection Details tab Field descriptions Sequence Number (1 to 4) that indicates the order in which the connections are used when connecting to SWIFTNet, or in case of failure. You must define at least one connection before the reception profile can be enabled. Conn Name Name of the SWIFTNet connection. Authoriser DN Authoriser DN associated with this connection. 15.3 Enabling and Activating SWIFTNet Profiles Introduction When you have configured an emission or reception profile, you must enable it to make it ready for use, and then activate it to start message traffic. You can also create schedules to allow profiles to be automatically "activated" and "deactivated". For more information, see "Scheduling Emission and Reception Profile Actions" on page 208. When enabling an emission profile, if a value specified in the emission profile does not match with the value in the Application Service Profile for the service selected, then a warning appears. When activated, an emission profile starts to check whether messages must be sent. At this stage, a connection is not established with SWIFT. When a message that must be sent is detected, a connection is established and the message sent. For a store-and-forward reception profile, an attempt to acquire a queue is made as soon as it is activated. If the reception profile fails to acquire the queue, then it becomes inactive. 15 July 2011 139 Alliance Access 7.0.20 Important Deactivating an emission or reception profile aborts all ongoing file transfers. In such a case, you are prompted to confirm the deactivation request. 15.3.1 Enabling and Activating Emission Profiles To enable an emission profile: 1. Select the emission profile that you want to enable from the Emission Profile list pane of the SWIFTNet Interface application. If the Emission Profile View window is not shown, then select Emission Profile from the View menu. 2. Select Enable from the Emission Profile menu. The profile status changes to Enabled. To activate an emission profile: 1. Select an emission profile that is currently inactive from the Emission Profile list pane. 2. Select Activate from the Emission Profile menu. The profile status changes to Activated. 15.3.2 Enabling and Activating Reception Profiles To enable a reception profile: 1. Select the reception profile that you want to enable from the Reception Profile list pane of the SWIFTNet Interface application. If the Reception Profile View window is not shown, then select Reception Profile from the View menu. 2. Select Enable from the Reception Profile menu. The profile status changes to Enabled. To activate a reception profile: 15.4 1. Select a reception profile that is currently inactive from the Reception Profile list pane. 2. Select Activate from the Reception Profile menu. The profile status changes to Activated. Set Up Input Channels 15.4.1 Conceptual Information 15.4.1.1 Input Channels Introduction The introduction of input channels and input sequence numbers (ISNs) in store-and-forward provides Sender-to-Receiver FIFO, gap detection, and duplicate detection. InterAct store-and-forward messages exchanged over these input channels are numbered sequentially. In the event of a transmission failure, the transmission is retried, using the same sequence number (without any additional PDE indication). For each input channel, store-and-forward maintains a sliding window of statuses of received messages and gaps between received messages. Within that window, it can identify duplicates and replay its original responses (accepted messages only, rejected messages are ignored by store-and-forward and considered as gaps). 140 System Management Guide Defining SWIFTNet Profiles The input channel is an attribute of store-and-forward emission profiles, defined in the SWIFTNet Interface application. The activation or de-activation of an emission profile (either manual or automatic) opens or closes the associated input channel if required. When Alliance Access opens an input channel, it logically establishes an input session with SWIFTNet and receives an input session token. During such an input session, the session token is repeated in all InterAct store-and-forward messages sent. These messages are numbered in sequence. The number of messages that can be sent by Alliance Access without receiving an acknowledgement is controlled by the input channel window size. This window size is defined at opening time and the sequence number of each message sent must be within it. Requirements Alliance Access uses input channels in an exclusive manner. This means that an Alliance Access instance cannot share an input channel for message transfer with any other application. When an emission profile is activated, the associated input channel may be opened in forced mode. This means that any message transfer by other applications using this channel are interrupted. Attempting to use the same input channel by several applications may cause a message transmission to be positively acknowledged even if the message was not actually sent over SWIFTNet. Setting up input channels When an institution subscribes for the first time to the store-and-forward service, SWIFT automatically creates two generic input channels for that institution (for live and pilot environments). Their names are <BIC8>_generic and <BIC8>_generic!p where <BIC8> is the BIC8 of the institution. Events are recorded to show the opening and closing of the input channel, and to log actions on the input channels (create, delete, adopt, and remove). Multiple emission profiles can use the same input channel. 15.4.2 Procedures 15.4.2.1 Create Input Channel Purpose This procedure enables you to create an input channel on SWIFTNet for one of your licensed BIC8. 15 July 2011 141 Alliance Access 7.0.20 Procedure 1. Run the SWIFTNet Interface application. 2. Select Input Channel from the View menu. The Input Channel window appears, showing the input channels defined: 3. Select Create on SWIFTNet from the Input Channel menu. The Create Input Channel window appears: 4. Type the Input Channel fields. • First subfield: the BIC8, 8 alphanumeric characters (lower-case letters only). • Second subfield: the reference. This is a free-text field, containing a maximum of 19 alphanumeric characters if the next field is present (otherwise the maximum is 21). • Third subfield: the environment: – x designates developer testing – p designates pilot operations (test and training) – No value designates live operations The Connection field is automatically filled with the first server of the list. 5. Use the drop-down lists if you want to select a different connection. 6. Select the Use Specific Authoriser DN check box, if required. Enter the value for the Authoriser DN. The value must comply with the distinguished name format, which is described in the SWIFTNet Naming and Addressing Guide. If you do not select this check box, then Alliance Gateway determines the DN to be used. Alliance Gateway selects a DN with the same BIC8 as in the Input Channel field. 7. 142 Click Create on SWIFTNet . System Management Guide Defining SWIFTNet Profiles 15.4.2.2 Delete Input Channel Prerequisites In Alliance Access, you can delete an input channel from SWIFTNet. The emission profiles configured with the selected input channel must be removed before the input channel can be deleted. Once deleted, the input channel cannot be recreated. Procedure 1. Run the SWIFTNet Interface application. 2. Select Input Channel from the View menu. The Input Channel window appears, showing the input channels defined: 3. Select the input channel required. 4. Select Delete from SWIFTNet from the Input Channel menu. The Delete Input Channel window appears: 5. Use the drop-down lists to select a different connection. 6. If required, select the Use Specific Authoriser DN checkbox. Enter the value for the Authoriser DN. The value must comply with the distinguished name format, which is described in the SWIFTNet Naming and Addressing Guide. If you do not select this check box, then Alliance Gateway determines the DN to be used. Alliance Gateway selects a DN with the same BIC8 as in the Input Channel field. 7. Click Delete from SWIFTNet . A confirmation message appears. 8. 15 July 2011 Click Yes . 143 Alliance Access 7.0.20 15.4.2.3 Adopt Input Channel Introduction You can adopt an input channel created by another application so that Alliance Access can use it. Procedure 1. Run the SWIFTNet Interface application. 2. Select Input Channel from the View menu. The Input Channel window appears, showing the input channels defined. 3. Select Adopt from the Input Channel menu. The Adopt Input Channel window appears: 4. Enter the input channel that you want to adopt. 5. Click Adopt . 15.4.2.4 Remove Input Channel Introduction Removing an input channel from Alliance Access does not delete it from SWIFTNet. The input channel remains on SWIFTNet, but it is no longer known by Alliance Access. Procedure 1. Run the SWIFTNet Interface application. 2. Select Input Channel from the View menu. The Input Channel window appears, showing the input channels defined. 3. Select the input channel to be removed. 4. Select Remove from the Input Channel menu. A confirmation window appears. 5. 144 Click Yes . System Management Guide Defining SWIFTNet Profiles 15.5 Set Up Output Channels 15.5.1 Conceptual Information 15.5.1.1 Output Channels Definition Output channels are used to identify output sessions with SWIFT. An output session is used to control the way and the order in which messages or files are delivered by SWIFT to the receiver. During an output session SWIFT delivers traffic to a messaging interface with an output sequence numbering which allows to control the order of delivery and to identify missing messages. Output sessions existed already before the concept of output channels was introduced. Output sessions were in fact queue sessions. At a given time only one session existed for a given queue. Starting an output session was equivalent to acquiring the queue. Stopping an output session was equivalent to releasing the queue. The concept of output channel allows multiple output sessions on a queue in such a way that these output sessions are easily identified and managed. Indeed, without output channels, there is only one output session possible at a given time for a queue, and there is only one output sequence numbering for that queue. That output sequence numbering is maintained across the output sessions, so that the order of the messages delivered from that queue can be established. When using output channels, each output channel has its own output sequence numbering maintained across output sessions for that output channel. When opening an output channel, traffic is delivered from the queue specified within the opening of the output channel. 15.5.2 Procedures 15.5.2.1 Delete an Output Channel Purpose This procedure enables you to delete an output channel from SWIFTNet. This procedure only deletes the output channel from SWIFTNet, the output channel remains in Alliance Access. You cannot recreate an output channel on SWIFTNet once it is deleted from SWIFTNet. Prerequisites You must remove the emission profiles configured with the selected output channel before you can delete the output channel from SWIFTNet. Procedure 1. Run the SWIFTNet Interface application. 2. Select Output Channel from the View menu. The Output Channel window appears, showing the output channels defined. 15 July 2011 145 Alliance Access 7.0.20 3. Select the input channel required. 4. Select Delete from SWIFTNet from the Output Channel menu. The Delete Output Channel window opens. 5. Click Delete from SWIFTNet . The Delete Output Channel from SWIFTNet window closes. The system deletes the output channel from SWIFTNet. 15.5.2.2 Adopt an Output Channel Purpose This procedure enables you to adopt an output channel from another application so that Alliance Access can use it. Procedure 1. Run the SWIFTNet Interface application. 2. Select Output Channel from the View menu. The Output Channel window appears, showing the output channels defined. 3. Select Adopt from the Output Channel menu. The Adopt Output Channel window opens. 4. Select the BIC8 that you require from the drop-down list in the first part of the Output Channel field. 5. Enter the remainder of the output channel name in the second and third parts of the Output Channel field, as necessary. 6. Click Adopt . The Adopt Output Channel window closes. 15.5.2.3 Remove an Output Channel Purpose This procedure enables you to remove an output channel from Alliance Access. This procedure only deletes the output channel from Alliance Access, the output channel remains on SWIFTNet. Procedure 1. Run the SWIFTNet Interface application. 2. Select Output Channel from the View menu. The Output Channel window appears, showing the output channels defined. 3. Select the output channel to be removed. 4. Select Remove from the Output Channel menu. A confirmation window appears. 146 System Management Guide Defining SWIFTNet Profiles 5. 15 July 2011 Click Yes . 147 Alliance Access 7.0.20 16 Configuring SWIFTNet Connections Introduction This section describes how to configure the SWIFTNet environment and access functions required to set up the environment. Alliance Workstation can be used to configure the SWIFTNet environment, and provides access to the functions required to set up the environment. This includes: • defining SWIFTNet connections • assigning a SWIFTNet connection to a logical terminal, and to emission and reception profiles. For this task, see: – "Assigning SWIFTNet Connections to a Logical Terminal" on page 155 for logical terminals – "Assigning SWIFTNet Connections to SWIFTNet Profiles" on page 134 for emission and reception profiles. For a description of the SWIFTNet environment and an explanation of SWIFTNet terms, see the Certificate Administration Guide, which is part of the SWIFTNet Link documentation. After installation, initial access to the SWIFTNet Support application is limited to the two Alliance Security Officers who have received the initial secrets, so it is the responsibility of these operators to configure the SWIFTNet environment. New operators can be defined, to allow the delegation of the different configuration aspects using entitlements and permissions. Note Alliance Access communicates with Alliance Gateway using the Relaxed SWIFTNet Link format. Tasks related to the management of certificates are performed on Alliance Gateway. For more information about these tasks, see the Alliance Gateway Operations Guide. For more information about certificates, see the Certificate Administration Guide. Definitions The following are terms used for SWIFTNet within Alliance Access: • SWIFTNet Connection: is the system (host name or IP Address and port number of the system running Alliance Gateway) on which the SWIFTNet Link software is installed. • Authoriser DN: is the Distinguished Name of the PKI certificate holder • CID Signing DN: is the Distinguished Name of the PKI certificate holder in the context of FIN Copy 16.1 About the SWIFTNet Support Application Overview The SWIFTNet Support application provides functions for defining SWIFTNet connections. When assigning permissions, ensure that Connection Handling is set to Yes. 148 System Management Guide Configuring SWIFTNet Connections For information about setting up operator profiles and permissions, see "Managing Alliance Access Security" on page 77. 16.2 Defining and Modifying SWIFTNet Connections Overview The SWIFTNet Connection window lists the available connection(s). From this window, you can create or maintain SWIFTNet connection(s). For a description of the fields displayed in this window, see "The SWIFTNet Connection Window" on page 149. From the SWIFTNet Connection window, you can: • add a SWIFTNet connection • modify a SWIFTNet connection • remove a SWIFTNet connection • mark a SWIFTNet connection as reliable. 16.2.1 The SWIFTNet Connection Window Description The SWIFTNet Connection window lists the available SWIFTNet connection(s). From this window, you can create or maintain SWIFTNet connection(s). Example of SWIFTNet Connection window Field descriptions Connection Name The user-defined name of the SWIFTNet connection. Hostname The host name of the machine on which Alliance Gateway is installed. Status The status of the connection. 16.2.2 Viewing the SWIFTNet Connections To view the SWIFTNet connection(s): 1. Run the SWIFTNet Support application. The SWIFTNet Connection window displays the SWIFTNet connections available. 15 July 2011 149 Alliance Access 7.0.20 2. Select the required SWIFTNet connection from the list and then Open from the SWIFTNet Connection menu. The SWIFTNet Connections Details window appears. The SWIFTNet Connections Details window lists the details for the selected SWIFTNet connection. For a description of the fields displayed in this window, see "The SWIFTNet Connection Details Window" on page 151. 16.2.3 Adding a SWIFTNet Connection To add a SWIFTNet connection: 1. Run the System Management application. 2. Stop the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS) components as described in "Stopping and Restarting Components" on page 74. 3. Run the SWIFTNet Support application. The SWIFTNet Connection window appears. 4. Select New... from the SWIFTNet Connection menu or click a connection in the list and select New As.... The SWIFTNet Connection Details window appears. 5. Provide the connection details. For a description of the fields displayed in this window, see "The SWIFTNet Connection Details Window" on page 151. 150 6. When you have entered the required data, select Add from the SWIFTNet Connection menu. 7. Restart the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS) components as described in "Stopping and Restarting Components" on page 74. System Management Guide Configuring SWIFTNet Connections 16.2.4 The SWIFTNet Connection Details Window Description The SWIFTNet Connection Details window allows you to specify details regarding your SWIFTNet connection. Example of SWIFTNet Connection Details window Field descriptions Connection Name Enter an identifier for the connection that you are defining. It must be unique. Hostname Enter the host name or IP address of the (remote) Alliance Gateway host. Port Number Enter the TCP port of the Alliance Gateway host. SSL (in SSL Settings pane) Select the type of security required for the communication between Alliance Access and Alliance Gateway (SSL is used to secure transactions using PKI). This can be: • No additional security - no additional security to be used • Data Encryption (default) - provides two-way encryption of data sent between Alliance Access and Alliance Gateway • Data Encryption/Host Authentication - provides two-way encryption of data sent between Alliance Access and Alliance Gateway. In addition, Alliance Access checks the SSL certificate of the Alliance Gateway to verify that it communicates with the Alliance Gateway that it expects. If you select Data Encryption/Host Authentication, then the SSL Certificate DN and CA Certificate fields become available. 15 July 2011 151 Alliance Access 7.0.20 SSL Certificate DN Enter the distinguished name of the SSL Certificate used by the Alliance Gateway Transport Agent. CA Certificate Enter the name of the file (without path) containing the CA certificate. A different CA certificate can be used for the authentication of each Alliance Gateway connection. The CA certificate must be available locally to Alliance Access: • Windows: %alliance%\data • UNIX: $ALLIANCE/data This certificate is used when establishing the low-level connection between Alliance Access and Alliance Gateway. LAU (in LAU Settings pane) LAU secures the link between Alliance Access and the SWIFTNet Link host, where the PKI signatures for FIN message authentication are calculated (on an HSM). LAU Key First Part / Second Part The LAU key consists of 32 printable characters and must be entered in two 16-character strings. This key must be the same as the one that is entered in the Alliance Gateway system and must be renewed at regular intervals. Only Alliance Access and Alliance Gateway or Alliance Starter Set know the LAU key that is exchanged with messages over this link. Each part of the LAU key must comply with the following password complexity rules: • a string of exactly 16 US-ASCII printable characters (from characters 32 to 126): – A-Z – a-z – 0-9 – ! "# $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ • the key must contain at least one upper-case and one lower-case alphabetic character • the key must contain at least one number • the number of occurrences of the same character must be equal to or less than half the number of characters in it, minus one. Connection Status Indicates whether the connection between Alliance Access and the SWIFTNet Link host is Reliable or Not Reliable. This parameter cannot be modified in this window. The SWIFTNet connection status can be monitored and modified from the SWIFTNet Connection window in the SWIFTNet Support application. The status can only be modified when the SIS and SNIS components are stopped. Port number (in FileAct Settings pane) Numeric input field. Default value is 48003. 152 System Management Guide Configuring SWIFTNet Connections SSL (in FileAct Settings pane) Select one of the following types of security required for the handling of File messages: • No additional security • Data Encryption (default). 16.2.5 Modifying a SWIFTNet Connection To modify a SWIFTNet connection: 1. Run the System Management application. 2. Stop the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS) components as described in "Stopping and Restarting Components" on page 74. 3. Run the SWIFTNet Support application. The SWIFTNet Connection window appears. 4. Click the connection which you want to update and from the SWIFTNet Connection menu select Open.... The SWIFTNet Connection Details window appears with the configuration information for this connection. For a description of the fields displayed in this window, see "The SWIFTNet Connection Details Window" on page 151. 5. The information in the following fields can be updated (depending on your configuration): • Hostname • Port Number 15 July 2011 153 Alliance Access 7.0.20 • SSL • SSL Certificate DN • CA Certificate • LAU • LAU Key First Part • Second Part (of LAU Key) For more information, see "The SWIFTNet Connection Details Window" on page 151. 6. When you have entered the required data, select Modify from the SWIFTNet Connection menu. The connection is now updated. All modifications to the SWIFTNet connection are logged in the event journal. 7. Restart the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS) components as described in "Stopping and Restarting Components" on page 74. 16.2.6 Removing a SWIFTNet Connection Overview You can remove a selected SWIFTNet connection if it is not assigned to a logical terminal, an emission profile, or to a reception profile. To remove a SWIFTNet connection: 1. Run the System Management application. 2. Stop the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS) components as described in "Stopping and Restarting Components" on page 74. 3. Run the SWIFTNet Support application. The SWIFTNet Connection window appears. 154 4. Click the connection to be removed and select Remove from the SWIFTNet Connection menu. 5. You are prompted with a dialog box to confirm the removal of the SWIFTNet connection. Click Continue to complete the process. 6. Restart the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS) components as described in "Stopping and Restarting Components" on page 74. System Management Guide Configuring SWIFTNet Connections 16.2.7 Marking a SWIFTNet Connection as Reliable Monitoring the local connection All processes that transfer FIN messages regularly verify the SWIFTNet connection status. If it is marked as Not reliable (the Local Authentication result contained an error), then the message transfer over this SWIFTNet connection is stopped immediately until the status becomes Reliable again. If a secondary connection is defined, then the message transfer can continue over this secondary connection if it is marked as Reliable. The SWIFTNet connection status can be checked and modified from the SWIFTNet Connection window. To mark a SWIFTNet connection as Reliable: 1. Run the System Management application. 2. Stop the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS) components as described in "Stopping and Restarting Components" on page 74. 3. Run the SWIFTNet Support application. The SWIFTNet Connection window appears. 16.3 4. Click the connection marked as Not reliable and select Mark Connection as Reliable from the SWIFTNet Connection menu. 5. Restart the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS) components as described in "Stopping and Restarting Components" on page 74. Assigning SWIFTNet Connections to a Logical Terminal Overview This section describes how to assign a SWIFTNet connection to the logical terminal. For more information about SWIFTNet connections, see "Configuring SWIFTNet Connections" on page 148. Prerequisites The servers must be running in Operational mode. Message partners with relaxed certificates If a connection to an Alliance Gateway is defined in Alliance Access without specifying an Authoriser DN, then Alliance Gateway selects any certificate that is defined for the destination in the Alliance Gateway message partner. 15 July 2011 155 Alliance Access 7.0.20 To prevent Alliance Gateway from using a non-FIN certificate for FIN messages, and vice versa, the Alliance Gateway message partners must be configured with the correct type of certificate, as follows: Alliance Gateway message partner Contain certificates which are valid for fin_<instance> FIN, which are associated with logical terminal connections for MT messages sni_<instance> non-FIN, which are associated with SWIFTNet Emission and Reception Profiles, for non-FIN messages To assign a SWIFTNet connection to a logical terminal: 1. From the System Management application, stop the SWIFT Interface Services (SIS) component, as described in "Stopping and Restarting Components" on page 74. 2. Run the SWIFT Interface application. 3. If the Logical Terminal list pane is not shown, then select Logical Terminal from the View menu. 4. Select a logical terminal in the list by double-clicking it or by using Open in the Logical Terminal menu. This opens the Logical Terminal Details window. 5. Click the Connection Details tab. Four connections can be defined for the logical terminal. The sequence number (1 to 4) indicates the order in which the connections are used when connecting to FIN, or in case of failure. 156 6. Select the SWIFTNet connection that you want to use for this logical terminal by clicking its entry in the list. Then select Assign Connection from the Logical Terminal menu. The Gateway Connection Details window appears. 7. Select the required connection from the Connection Name field. System Management Guide Configuring SWIFTNet Connections 8. Select the Use specific Authoriser DN option to specify the Authoriser DN. Type the Authoriser DN value, which must comply with the DN format described in the SWIFTNet Naming and Addressing Guide. For more information about the result of selecting this item, see the "Authorisor DN and CID Signing DN" on page 157. 9. Select the Use specific CID Signing DN to specify the CID Signing DN. This DN is used in the context of FIN Copy for the central institution. If you select this box, then the CID Signing DN field appears. Enter the required CID Signing DN. For more information about the result of selecting this item, see the "Authorisor DN and CID Signing DN" on page 157. 10. Click OK . The selected SWIFTNet connection is now available to this logical terminal. 11. Restart the SWIFT Interface Services (SIS) component, as described in "Stopping and Restarting Components" on page 74. You can schedule different actions for logical terminals. For more information, see "Scheduling FIN Select or Logout from SWIFT" on page 205. Note Authorisor DN and CID Signing DN The following table outlines the result of entering values, or not, for Authorisor DN and CID Signing DN: If you select Use Specific Authoriser DN ✓ ✓ The result is Use specific CID Signing DN The distinguished name that user provided for the Authoriser DN field becomes the value of both the Authoriser DN and the CID signing DN ✓ The distinguished name that user provided for the CID signing DN is assigned only to the CID signing DN. The field becomes the value of Authoriser DN remains unchanged. ✓ The Authoriser DN and the CID Signing DN are assigned the values that the user provided in the Authoriser DN and in the CID Signing DN , respectively Alliance Gateway determines the Authoriser DN to be used. • Authoriser DN The level 2 of the DN selected by Alliance Gateway must match the BIC8 provided by Alliance Access • CID signing DN The level 2 of the DN selected by Alliance Gateway matches the BIC8 provided by Alliance Access for the FIN Copy service. 15 July 2011 157 Alliance Access 7.0.20 17 Configuring System Parameters Introduction Alliance Access contains a number of system parameters that you can configure using the System Management application. Whether you can modify parameters depends on your operator profile. This section lists all system configuration parameters and describes how you can use the System Management application to view or modify their value. 17.1 Modifying Parameters To modify a parameter: 1. Run the System Management application. 2. If the configuration parameters are not shown, then select Configuration from the View menu. The parameters are listed within a window. The following details are displayed for each configuration parameter: 3. Field Description Component The application affected by the parameter Object The class to which the parameter belongs, such as display format, alarm, or disk space Parameter The name of the configuration parameter Double-click the parameter that you want to modify from the Configuration list. A Configuration Details window appears. For a description of the fields displayed in this window, see "Configuration Details Window" on page 159. 4. Modify the Value field. 5. Select Modify from the Configuration menu to save the changes. Note 158 For changes to take effect, it is sometimes necessary to restart the application, to restart the servers, to wait for a delay, and so on. For more information, see the specific parameter descriptions in "Classes of Configuration Parameters" on page 159. System Management Guide Configuring System Parameters 17.2 Configuration Details Window Description The Configuration Details window appears when you double-click a parameter in the configuration list. Example of Configuration Details window Field descriptions Component The application affected by the setting of the parameter. Object A general classification given to the parameter. Parameter The name of the parameter. Value The attribute of the parameter that can be modified. Default The default value of the parameter. SWIFT set this value and it cannot be modified or set during installation. Min allowed The minimum value allowed for the parameter. This is only applicable to numeric values. Max allowed The maximum value allowed for the parameter. This is only applicable to numeric values. Description A description of what the parameter does. 17.3 Classes of Configuration Parameters Overview Alliance Access contains a number of parameters that you can configure. You can change the values of these parameters only if the permissions of your operator profile permit you to change them. 15 July 2011 159 Alliance Access 7.0.20 Configuration parameters are grouped by class. Note Some parameters described in this section are only available if you have licensed the relevant option for your system. 17.3.1 Alarm List of alarm parameters Parameter Description Maximum The maximum number of alarms that can be popped up on a Workstation at one time. Default value: 3. Changes to this parameter take effect at the next Workstation login. Timeout The number of minutes an alarm popup remains on screen. Default value: 15. Changes to this parameter take effect at the next Workstation login. 17.3.2 Alarm Message List of alarm message parameters Parameter Description Sender LT Specifies the logical terminal (BIC12: LT followed by XXX) used to send alarm messages to Internal Correspondents. Changes to this parameter take effect at the Next Alarm Message/Frequency check. Frequency Alarm Message/Frequency check (in minutes). Default value: 5. Changes to this parameter take effect at the next check. 17.3.3 Backup List of backup parameters 160 Parameter Description Archive Backup Dir Object The Oracle database requires this parameter to create the Data Pump files containing the backups of archives. Maximum value: 30. A change to this parameter will be taken into account at the next backup or restore operation. This parameter is only available when the Alliance Access database is hosted. DB Backup Dir Object The Oracle database requires this parameter to create the Data Pump files containing the backups of the Alliance Access database. Maximum value: 30. A change to this parameter will be taken into account at the next backup or restore operation. This parameter is only available when the Alliance Access database is hosted. System Management Guide Configuring System Parameters Parameter Description Location Backups This parameter defines the file directory wherein the Alliance Access backups are created. This directory must be shared between the Alliance Access host and the database host. If the parameter has no value, then no backup or restore can take place. The parameter has no value by default. A change to this parameter will be taken into account at the next backup or restore operation. This parameter is only available when the Alliance Access database is hosted. Location Backups DB Host This parameter defines the file directory remotely accessed from the database host wherein the Alliance Access backups are created. If this parameter has no value, then the value specified for the Location Backups parameter is used. The parameter has no value by default. A change to this parameter will be taken into account at the next backup or restore operation. This parameter is only available when the Alliance Access database is hosted. 17.3.4 Batch Input List of batch input parameters Parameter Description History Period The number of days to keep history records for batch duplication check and to keep the files in the file transfer adapter backup and error directories. Default value: 10. Changes to this parameter take place at the next poll. Automatic Backup Dir Automatic Input Backup Directory. All files in this directory that are older than the Batch Input History Period are deleted. Default: C:\Alliance\Access\usrdata\FTA\back Changes to this parameter take place at the next poll. Automatic - Error Dir Automatic Input Error Directory. All files in this directory that are older than the Batch Input History Period are deleted. For more information about the use of this parameter, see "Recovery of Batch Sessions" on page 573. Default: C:\Alliance\Access\usrdata\FTA\error Changes to this parameter take place at the next poll. 15 July 2011 Automatic Polling Timer The Session Autostarter Polling Timer in seconds. Default value: 60. Changes to this parameter take place at the next poll. Log Directory The location where report files generated for XML version 2 (MT/MX) input are stored. 161 Alliance Access 7.0.20 17.3.5 Batch Output List of batch output parameters Parameter Description LTA Timeout Defines the Local Transfer Agent completion time in minutes. This is the time that Alliance allows for the Local Transfer Agent to process a batch output file. If the Local Transfer Agent has not finished its task within this time, then an event is written to the Event Journal. Default value: 5. LTA waiting mode Specifies whether Alliance can wait for Local Transfer Agent completion before closing the session. Default value: Off. 17.3.6 Database List of database parameters This parameter is not available when the licence package 13:HOSTED DATABASE is present. Parameter Description Location Messages Location of the daily Messages database files. A change to this parameter is taken into account on creation of the next database file. Note: if the user enters an invalid path or if the server processes have no write access to the specified location, then the new database files are created in the following directory: • On UNIX: $ALLIANCE/database/datafiles/MESG • On Windows: %ALLIANCE%\database\datafiles\MESG Location Journal Events Location of the daily Journal Events database files. A change to this parameter takes effect at the next database file creation time. Note: if the user enters an invalid path or if the server processes have no write access to the specified location, then the new database files are created in the following directory: • On UNIX: $ALLIANCE/database/datafiles/JRNL • On Windows: %ALLIANCE%\database\datafiles\JRNL 17.3.7 Alliance Access Developers Kit List of Alliance Access Developers Kit parameters Parameter Description ADK Storage This parameter defines the directory in which Alliance Access Developers Kit applications can store their specific information. The contents of this directory are considered during the backup and restore operations. The default path for this directory is as follows: • On Windows: %ALLIANCE%\data\ADK_DIR • On UNIX: $ALLIANCE/data/ADK_DIR 162 System Management Guide Configuring System Parameters Parameter Description Operational Trace When this parameter has a value On, a journal entry is written for every call that is made to an Alliance Access Developers Kit (Toolkit) function. The journal entry describes in full the call made by the Alliance Access Developers Kit function. Default value: Off. A change to this parameter takes effect when an Alliance Access Developers Kit application is restarted. 17.3.8 Disk Space List of disk space parameters Parameter Description Frequency The interval in seconds (in multiples of 60) at which disk space is checked. Default value: 300. Minimum: 120. Maximum: 3600. Change to this parameter takes effect at the next check. A warning will be given if free disk space drops below a Warning parameter. Repeat warnings are given at 10 times the interval. Recovery Shutdown - MB Alliance Access shuts down when the free space of the Recovery Backup Disk becomes less than this number of megabytes. If the value is 0, then no action is taken. Default value: 1000. Minimum: 0. Maximum: 4190000. This parameter is available when 14:DATABASE RECOVERY is licensed. Recovery Warning - MB Alliance Access issues a warning when the free space of the Recovery Backup Disk becomes less than this number of megabytes. If the value is 0, then no action is taken. Default value: 5000. Minimum: 0. Maximum: 4190000. This parameter is available when 14:DATABASE RECOVERY is licensed. Shutdown - MB Sets the absolute minimum free disk space (in MB) that must be available on the file systems hosting the database. If the free disk space available for one of these file systems falls below this value, then Alliance Access shuts down. Default value: 1000, to which the system automatically adds (for recovery purposes) the size of the largest database file stored in the database, plus the size of the database index file. Minimum: 0. Maximum: 4190000. The frequency at which this parameter is checked is set using the Disk Space Frequency parameter. Alliance must be restarted before a change to the value of this parameter becomes effective. 15 July 2011 Shutdown Release Dir Shutdown Alliance Access when available space on the disk of the source tree is less than this value (in Kbytes). Default value: 20000. Changes to this parameter take effect at the next disk space check. Warning - MB Alliance Access issues a warning when the free space of one of the monitored file systems hosting the database becomes less than this number of megabytes. The file system is set in an exception state in the resources monitoring. Default value: 5000. Minimum: 0. Maximum: 4190000. If the value is 0, then no action is taken. Changes to this parameter take effect at the next disk space check. Warning Release Dir Alliance Access issues a warning when available space on the disk of the Release Directory is less than this value. Default value: 50000 (Kbytes). Changes to this parameter take effect at the next disk space check. 163 Alliance Access 7.0.20 Parameter Description UNIX only: Alliance Access issues a warning when available space on the /tmp disk is less than this value (in Kbytes). Default value: 10000. Minimum: 1024. Maximum: 200000. Changes to this parameter take effect at the next disk space check. Warning - Printer Spool 17.3.9 Display Format List of display format parameters Parameter Description Amount Specifies the convention used to separate decimals and units of a thousand: • Decimal-Comma/Thousand-Nothing, which corresponds to the ISO format. This is the default value. • Decimal-Point/Thousand-comma, which corresponds to the American format. • Decimal-Comma/Thousand-Point, which corresponds to the European format. Date The display format of the date: American date format is MM/DD/YY, European date format is DD/MM/YY, ISO date format is YY/MM/DD. A change to this parameter takes effect when Alliance Workstation is restarted. Default: European. Time Specifies the time format: • Day of 24 Hours, which uses 24-hour clock notation, for example, 13:15:00. This is the default option. • Day of 12 Hours, which uses 12-hour clock notation, for example, 01:15:00 p.m. See also the "Display/Print" on page 164 class of parameters. 17.3.10 Display/Print Display/Print parameter Parameter Description FIN User Header Specifies whether to display or print the FIN User Header (block 3) of MT messages. The allowed values are: • Yes - display block 3 in the message details in the Text tab of theMessage File Application, and in the results of a message search. In addition, print block 3 in the printed reports of message details, both from the GUI and from a Print message partner. • No - do not display block 3 in the message details, and do not print it in reports that provide message details. The default value is No. 164 System Management Guide Configuring System Parameters 17.3.11 Emission List of emission parameters Parameter Description Retry Timer Indicates the timeout period (in seconds) between 2 retries to emit a message. The value entered can be from 0 to 120 seconds. Default value: 60. The SNIS component must be restarted before changes to this parameter take effect. 17.3.12 Event Event parameter Parameter Description SNMP Max Event Size Indicates the maximum size of the event text distributed to SNMP managers. 0 means that there is no maximum size. Default value: 2000. 17.3.13 File File parameter Parameter Description File Digest Algorithm Indicates the default file digest algorithm that Alliance Access uses to compute the digest on the payload file of the FileAct message if no file digest algorithm is provided by the back-office application. The following values exist: SHA-1 and SHA-256. Default value: SHA-256. Changes to this parameter take effect immediately. 17.3.14 Message List of message parameters Parameter Description Expansion Language Specifies the language that message expansion fields are displayed in. Default value: English. A change to this parameter takes effect when an application is restarted. LT load balancing Enables automatic logical terminal allocation. Possible values are: • On - the messages originated by a destination can be transmitted by any logical terminal of this destination which is logged in. • Off - the logical terminal specified in the message transmits the message. Default value: Off. Changes to this parameter only take effect after the SIS component is restarted. 15 July 2011 165 Alliance Access 7.0.20 Parameter Description RMA authorisation for T&T Specifies whether RMA Authorisation is required for FIN Test and Training messages. Possible values are: • Not required • Required Default value: Not required. Changes to this parameter will only take effect after the SIS component is restarted. RTV Routing Controls the RTV routing information in a retrieved message. When this parameter is set to: • Off - the routing_code field for a retrieved message is set to RTV • On - the disposition_address_code field for a retrieved message is set to RTV. The SIS component must be restarted for changes to this parameter to take effect. Default value: Off. Common Ref Calculation Controls the calculation of the Common Reference, which is part of field 22 of Block 4, in FIN messages that are input through message partners and that have the data format CAS, RJE, DOS-PCC, or XML version 2. Alliance Access always calculates the Common Reference in messages that a user enters manually. The values are: • Yes - Alliance Access calculates the Common Reference, even it exists in field 22. • No - does not calculate the Common Reference in field 22. In this case, the values of Validation level and Message Modification allowed are ignored, and a NAK may be received if field 22 of the message contains incorrect information. Default value: Yes. The MXS component must be restarted for changes to this parameter to take effect. 17.3.15 Network List of network parameters 166 Parameter Description SWIFTNet Batching Timeout Maximum delay (in seconds) that Alliance buffers an input message before it is sent. SWIFT determines the final value used. Default value: 2. The SIS component must be restarted before changes to this parameter take effect. SWIFTNet Max batch count Maximum number of FIN APDUs that can be sent in a single DATA PDU. SWIFT determines the final value used. Default value: 30. The SIS component must be restarted before changes to this parameter take effect. Reconnect Timer Indicates the time (in minutes) after which the SWIFTNet Interface component (SNIS) attempts to reconnect an interrupted profile. Default value: 20. Minimum: 1. Maximum: 300. The SWIFTNet Interface component must be restarted for changes to this parameter to take effect. System Management Guide Configuring System Parameters Parameter Description Preferred Order Used by the Message Preparation application to propose a default value for the preferred network when the receiver is a wild address, that is, the network address is not in the correspondent file. The default display order is SWIFT, APPLI, OTHER. A change to this parameter takes effect when the application is restarted. Usersync - Max Retries Specifies the number of attempts that are allowed to reconnect a failed communication session with the SWIFT network. Default value: 20. The SWIFT Interface component must be restarted for changes to this parameter to take effect. Usersync - Max Time Specifies the duration (in minutes) for which attempts to reconnect a failed communication session with the SWIFT network are made. Default value: 30. The SWIFT Interface component must be restarted for changes to this parameter to take effect. Usersync - Retry Timer Specifies the time-out period (in seconds) between reconnect retries. Default value: 120. The SWIFT Interface component must be restarted for changes to this parameter to take effect. Delivery Notif via SysMsg Specifies whether SWIFTNet delivery notifications for InterAct or FileAct messages can be received as system messages. If this parameter is set to No, then SWIFTNet delivery notifications are received as internal messages. Default value: No. The SWIFTNet Interface component must be restarted for changes to this parameter to take effect. 17.3.16 Performance List of performance parameters 15 July 2011 Parameter Description Active Correspondent Controls whether correspondents are checked to see whether they have an active status, before sending a message. The possible values are "On" or "Off". Default value: On. The SWIFT Interface Services must be restarted for changes to this parameter to take effect. FIN Keyword Extraction Controls whether keywords are extracted from incoming (output) MT messages. The possible values are "On" or "Off". Default value: On. The SWIFT Interface Services must be restarted for changes to this parameter to take effect. Maximum Read Rate Disk I/O in MB/sec used to read from the database disks when a Recovery Backup is created. Minimum: 0. Maximum: 1024. Default value: 0. If the value is 0, then maximum disk I/O is used. A change to this parameter takes effect at the next recovery backup creation. This parameter is ignored unless the Alliance servers are running and option 14:DATABASE RECOVERY is licensed. MQSA Interventions Controls whether the writing of some interventions is suppressed. The possible values are "None", "All", or "System". Default value: None. The SMQS component must be restarted for changes to this parameter to take effect. This parameter applies to MQSA. It does not apply to the WebSphere MQ Host Adapter. 167 Alliance Access 7.0.20 Parameter Description MX Keyword Extraction Controls whether keywords are extracted from incoming (output) MX messages. The possible values are "On" or "Off". Default value: On. The SWIFTNet Interface Services must be restarted for the changes to this parameter to take effect. Routing Intervention Controls what types of interventions are suppressed. The possible values "All", "System generated only", or "None". Default value: None. 17.3.17 Print List of print parameters Parameter Description Message Search Results Specifies the maximum number of items that can be printed in a Message Search Report. Default value: 1024. The value "0" means that no limit is set. Skip Interventions Specifies whether Printer message partners print notifications without system or user interventions. This does not apply to transmission notifications. The default value is No, with notifications being printed with system or user interventions. Setting this parameter to Yes saves paper when notifications are printed. ST200-like Format Specifies whether Printer message partners print messages in an ST200-like format, with an eye-catcher and warning banner. This parameter has no effect when messages are printed to a file. Default value: No. See also the "Display/Print" on page 164 class of parameters. 17.3.18 Queue Queue parameter Parameter Description Threshold Frequency of alarm generation - the number of messages that can be added above a queue threshold or the number of overdue message instances before a new alarm will be generated. Minimum: 20. Maximum: 100. Default value: 20. Changes to this parameter take effect at the next alarm. 17.3.19 Receiver List of receiver parameters 168 Parameter Description Default HQ for MT074 Specifies the receiver for system messages 074. Default value: SWHQBEBBBCT. Default HQ for MT090 Specifies the receiver for system messages 090. Default value: SWHQNLNLXXX. System Management Guide Configuring System Parameters 17.3.20 RMA RMA parameter Parameter Description Auto Refresh If this parameter is set to No, then the automatic refresh of the view lists is disabled in the Relationship Management application. Default value: Yes. Changes to this parameter take effect after restarting the Relationship Management application. 17.3.21 Shutdown List of shutdown parameters Parameter Description Delayed After a request to stop the servers, this is the number of seconds delay before the GUI applications are terminated. Default value: 120. Forced After a request to stop the servers, this is the number of seconds delay before the server processes are terminated. Normally the server processes stop before this time has elapsed. Default value: 240. 17.3.22 System System parameter Parameter Description Startup Mode On UNIX, this parameter can have the following values: • Automatic - Alliance Access starts as a result of starting the Alliance Access bootstrap • Manual - An operator must explicitly start Alliance Access. Default value: Manual. On Windows, this parameter can have the following values: • Service - Alliance Access runs as a Windows service under control of the Alliance Access Bootstrap service. In Service mode, mapped network drives cannot be used. • Normal - Alliance Access does not run as a Windows service. Default value: Normal. 17.3.23 Traffic Recon Traffic Recon parameter 15 July 2011 Parameter Description Delivery Notif If set to Yes, then Traffic Reconciliation generates notifications for each matched message instance. Default value: Yes. 169 Alliance Access 7.0.20 17.3.24 WebSphere MQ List of WebSphere MQ parameters If the licence package 13:MQ HOST ADAPTER is installed, then the following parameters are available in the System Management application: Parameter Description Connection Mode Specifies the mode that the MQ interface of Alliance Access uses to connect to a Queue Manager. The options are: • Client - The MQ interface can connect to multiple Queue Managers which are located on the same host or on a different host as the MQ Adapter. Note See the WebSphere MQ Interface User Guide for information about setting the environment variables for "MQSERVER" and "MQ channel table". • Server - The MQ interface can connect to Queue Managers located on the same host as Alliance Access. Default value: Server. A change to this parameter takes effect after the MXS component is restarted. 170 Input Message Rate Limit Limits the number of messages that Alliance Access reads per second from all the WebSphere MQ queues that are configured in Alliance Access. The default value is 0, which means that the incoming MQ traffic is not limited. Mininum: 0. Maximum: 999. Before you change this parameter, you must disable all the MQ message partners. Recovery Time Initial The time interval, in seconds, after which the first attempt to reopen the communication session with WebSphere MQ is made in case of a broken connection. Default value: 60. Recovery Time Increment The increase of the time interval, in seconds, between consecutive attempts to reopen a WebSphere MQ session. Default value: 30. Recovery Time Max The maximum time interval, in seconds, between consecutive attempts to reopen a WebSphere MQ session. Default value: 600. System Management Guide Configuring Event and Alarm Distribution 18 Configuring Event and Alarm Distribution Introduction This section describes what events and alarms are, and how to administer them using the System Management application. Events are reports about actions in Alliance Access. Each event contains detailed information about the action. Events are grouped into event types, according to the Alliance Access function or application that generated the event. Modifying attributes of an event affects all future instances of the selected event, but not those already logged in the Event Journal. Alarms are events which have been promoted so that they have alarm status. Alarms are classified as either For Action or For Information. You configure alarm and event distribution using the System Management application. 18.1 Event Distribution Overview Once an event has been set as an alarm, it is always recorded in the Event Journal and details of the alarm can be distributed to operators and internal correspondents using the distribution lists. Event distribution to SNMP Manager applications Events can also be distributed to SNMP Manager applications (such as HP OpenView or Tivoli products) so that external applications can monitor events. The supported version of the SNMP protocol is Version 1. Note If an event is to be sent to an SNMP server, then it must be configured as an alarm, and that alarm must be sent to a distribution list that has an SNMP server configured (see "Promoting an Event to an Alarm"). If you do not want some events to be distributed because they contain confidential information, then you must set up your distribution lists accordingly. In addition, it is possible to not log the FIN message payload in the events. Security officers can set the related security configuration parameter. 18.1.1 Displaying Event Distribution Overview You can display or modify the status and distribution of the event types. For information about modifying event distribution, see "Modifying Event Distribution" on page 176. The number of events listed is dependent on whether you are using a high speed or low speed connection. If more than the defined number of events are present, then there is more than one list. 15 July 2011 171 Alliance Access 7.0.20 To display event types: 1. Run the System Management application. 2. From the View menu, select Event Distribution. The Event Distribution window appears, displaying the list of event types. To navigate between events lists: • From the Event Distribution menu, select Next list or Previous list. Further information about the distribution of an event can be displayed by selecting it from the Event Distribution window. To view detailed information about the distribution of an event, either double-click the event list or select it and select Open from the Event Distribution menu. 18.1.2 Event Distribution Window Description The events are listed by a number of options, such as the name and the class of the event. You can choose not to display these options by selecting View from the Event menu. If you select Save Current Settings from the File menu, then all your current settings are saved. The next time that you start the System Management application these settings are displayed automatically. 172 System Management Guide Configuring Event and Alarm Distribution Example of Event Distribution window Field description Comp. The applications in Alliance Access where the event occurred. Number A unique number that identifies the Event in Alliance Access. Name The name of the event. Class The functional domain to which the event belongs. Alarm Specifies whether the event has the status of an alarm or not. If the value is True, then two separate fields, Type and Distribute Alarm appear in the Alarm Info tab. Distribution The values can be: • Fixed: fixed events are always logged in the Event Journal. If an event has Fixed as its default setting, then it cannot be modified. • Journalise: the event will be journalised. 15 July 2011 173 Alliance Access 7.0.20 • Ignore: the event will not be journalised. 18.1.3 Event Distribution Details Window Description The Event Distribution Details window appears after selecting an Event type in the Event Distribution window and selecting Open from the Event Distribution menu. The window contains a General Info tab which displays the attributes of the event type. If the event type has the attribute Alarm set to True, then an Alarm Info tab appears which contains the Alarm specifics. 18.1.3.1 General InfoTab Description The General Info tab displays the attributes of the event type. Example of Event Distribution Details window Field descriptions Component The applications in Alliance Access where the event occurred. Number A unique number that identifies the Event in Alliance Access. Config Mgmt This allows you to mark the event as being related to Configuration Management. In the Event Journal, it is possible to search on events based on this criterion. Name The name of the event. Class The functional domain to which the event belongs. 174 System Management Guide Configuring Event and Alarm Distribution Severity Indicates the severity of an event. An event can have one of the following levels of severity: • Information • Warning • Severe • Fatal Distribution This option button is used to specify the distribution of events within the system and the values are: • Fixed: Fixed events are always logged in the Event Journal. If an event has Fixed as its default setting, then it cannot be modified • Journalise: The event is journalised • Ignore: The event is not journalised. Default Distribution This field specifies the default distribution set at installation time. It is the value which is set by the reset command. Security Specifies whether the event is related to security or not. This value cannot be altered. Alarm Specifies whether the event has the status of an alarm or not. If the value is True, then two separate fields, Type and Distribute Alarm appear in the Alarm Info tab. For information about this tab, see "Alarm Info Tab" on page 175. Text Displays a detailed description of the system or operator action that generated the event. 18.1.3.2 Alarm Info Tab Description The Alarm Info tab can be selected from the Event Distribution Details window. This tab is only present if the event that you selected is an alarm. 15 July 2011 175 Alliance Access 7.0.20 Example of Alarm Info tab Field descriptions Type If the event is an alarm, then you can select Action to indicate that action must be taken by the operator to clear the event, or Information to indicate that the event is for information only, and no action needs to be taken. Distribute Alarm To specify whether the alarm is to be distributed. If you select True, then the To Distribution List field appears. To Distribution List Click this option button to display the available distribution lists. To select a list, highlight it and click Select. 18.1.4 Modifying Event Distribution To modify event distribution: 1. Modify the event type as required using the options described in "Event Distribution Details Window" on page 174. 2. From the Event Distribution menu, select Modify to update the event details. 18.1.5 Resetting Default Event Distribution Overview At installation, each event has a default distribution value. The values are: • Fixed: fixed events are always logged in the event journal. If an event has Fixed as its default setting, then it cannot be modified. • Journalise: the event is journalised. • Ignore: the event is not journalised. 176 System Management Guide Configuring Event and Alarm Distribution It is possible to reset the attributes for event distribution back to their default settings. Events already logged in the Event Journal are not affected by this command. To reset default event distribution: 1. Run the System Management application. 2. From the File menu, select Reset Default Distribution. 18.1.6 Promoting an Event to an Alarm Overview You can promote events so that they have alarm status. This means that these events are automatically sent to the Event Journal and an alarm broadcast to the relevant operators. Alarms can also be sent to an SNMP server, providing that the distribution list has an SNMP server configured. Note If the following events are promoted to alarm status, then they can be distributed to internal correspondents. However, they cannot be distributed to specific operators. Component Number Name BSS 2007 Process started BSS 2008 Process terminated BSS 2016 Control process status change BSS 2019 Signature error BSS 2023 Process aborted BSS 2050 Process crashed BSS 2051 Process failed BSS 2052 Process succeeded To promote an event to an alarm: 1. Run the System Management application. 2. From the View menu, select Event Distribution. The Event Distribution window appears, displaying the list of event types. 3. From the Event Distribution window, select and open an event type. The Event Distribution Details window appears. 4. Click the General Info tab, then click Alarm and select True 5. Click the Alarm tab, then click Type and select one of the following: • Action, to indicate that the operator must take action to clear the alarm • Information, to indicate that the event is for information only and that no action needs to be taken. 6. 15 July 2011 Click Distribute Alarm and select True to broadcast the alarm. 177 Alliance Access 7.0.20 18.2 7. Click To Distribution List and select a distribution list to which the alarm must be broadcasted. For more information about distribution lists, see "Alarm Distribution" on page 178. 8. Click Modify . Alarm Distribution Overview The list of operators or internal correspondents to whom alarms are sent is called a distribution list. Alliance Access uses the distribution list to dispatch alarms. It is possible to customise this dispatching for each event. If an event is marked as an alarm to be distributed, and the assigned distribution list has been defined such that it distributes the alarm to operators, then an internal alarm is requested for distribution. This is broadcast to operators specified in the distribution list. If an alarm is marked For Action, then the first operator in the list receives this alarm and all other operators in the list receive the alarm for information purposes only. If nobody in the distribution list is signed on, then the alarm is sent to the Event Journal marked as untreated. If an event is marked as an alarm to be distributed, and the assigned distribution list has been defined such that it distributes the alarm to internal correspondents, then an MT 999 containing the alarm is generated. It is routed in the inbound queue of the preferred network assigned to the internal correspondent, as specified in the CIFA. For example, if the network is APPLI, the MT 999 is routed to a predefined exit point. Alarms can also be distributed to SNMP Manager applications (such as HP OpenView or Tivoli products) so that they can be monitored by external applications. Alarms sent to an SNMP Manager application include the Enterprise ID 18494 (which is the identification given to SWIFT by the Internet Assigned Numbers Authority) and the additional identifying information "2" for Alliance Access. The description and structure of alarms that Alliance Access sends to an SNMP manager is described in the file saatrap.mib. Depending on the platform, the file is located in the following directory: • on AIX: $ALLIANCE/BSS/data/AIX • on Oracle Solaris: $ALLIANCE/BSS/data/SunOS • on Windows: %ALLIANCE%\BSS\data/win32 All information concerning a single event is mapped to a structure that can be interpreted by the SNMP Manager based on the object identifier (or OID). Note Version 1 of the SNMP protocol does not offer specific protection such as encryption. The structure of each alarm includes the following information: 178 Field OID Description Unique identifier of the SAA instance .1 Differentiates events coming from more than one Alliance instance Date .2 Date, expressed as dd/mm/yyyy Time .3 Time, expressed as hh:mm:ss System Management Guide Configuring Event and Alarm Distribution Field OID Description Generated by .4 Component (as per the event template) Event number .5 32 bits Event severity .6 Severity (Fatal, Severe, Warning, or Information) Event class .7 Class (Operator, Data, Backup/Restore, Restart/Stop, Update BIC, Process, System, Software, Message, Communication, Security, Network Event name .8 Name (as per the event template) Event description .9 The actual event text 18.2.1 Displaying Alarm Distribution Overview You can display or modify the list of operators who receive alarms. For information about modifying alarm distribution, see "Modifying Alarm Distribution" on page 182. Note The default distribution lists are based on the class of the event. They can contain a maximum of 52 operators. To display alarm distribution: 1. Run the System Management application. 2. From the View menu, select Distribution List. The Distribution List window appears, displaying the available distribution lists. The distribution lists are shown with a number of options, such as the name of the list. You can choose not to display these options by selecting View from the Distribution List menu. If you select Save Current Settings from the File menu, then all your current settings are saved. The next time that you start the System Management application these settings are displayed automatically. 18.2.2 Navigating Between Distribution List Pages Overview The number of distribution lists is dependent on whether you are using a high speed or low speed connection. If more than the defined number of distribution lists are present, then there are more than one page. 15 July 2011 179 Alliance Access 7.0.20 To navigate between distribution list pages: • From the Distribution List menu, select Next List or Previous List. Further information about the distribution list can be displayed by selecting it from the Distribution List window. To view detailed information about the distribution of an event, either double-click the event list or select it and select Open from the Distribution List menu. 18.2.3 Distribution List Details Window Description The Distribution List Details window appears after selecting a Distribution List from those displayed in the Distribution List view. The window contains a General Info tab which displays the operators to which the event is to be distributed, that is, all or selected operators. The second tab Internal Correspondents is used to specify the internal correspondents to which the event report may also be directed. Example Field descriptions Distribution List The name of the distribution list, which describes the class of the selected event. Distribute Event to From this option box, you can select: • All operators: This sends an alarm to all operators who are signed on • Specific operators: This sends the alarm to operators who are signed on and specified as selected in the operator list pane. Operators This pair of transfer panes is used to specify the operators who are to receive the alarms belonging to the distribution list. If an alarm is marked For Action, then the first operator in the list, who is signed on, automatically receives this alarm. All other operators in the list, who are signed on, receive the alarm for information purposes only. 180 System Management Guide Configuring Event and Alarm Distribution 18.2.4 Internal Correspondents Tab Description The Internal Correspondents tab can be selected from the Distribution List Details window. This tab shows details about the distribution of the distribution list that you selected. Example Field descriptions Internal Correspondents This pair of transfer panes is used to specify the internal correspondents who are to receive alarms. The Available list displays all the internal correspondents defined in Alliance Access. 18.2.5 SNMP Servers Tab Description Allows you to specify, for each distribution list, one or more value pairs for the IP address, and port on which the SNMP Manager is listening for events. 15 July 2011 181 Alliance Access 7.0.20 Example Field descriptions Distribute event to SNMP Server(s): The destinations are expressed in the format <IP>:<port>, each occurrence on a separate line. Up to 16 destinations can be specified. 18.2.6 Modifying Alarm Distribution To modify the alarm distribution: 182 1. Click Operators to direct the alarm to All Operators or Specific Operators. 2. If you select Specific Operators, then the Operators list pane appears. The operators that have already been assigned appear in the Selected column. Those that are not assigned appear in the Available column. 3. To add an operator to the distribution list, double-click the operator in the Available list pane to move this operator to the Selected list pane. The first operator in the Selected list who is signed on, automatically receives the For Action alarm whilst all the other operators receive the alarm For information only. To remove an operator from the distribution list, double-click the operator in the Selected list pane to move this operator to the Available list pane. 4. Click the Internal Correspondents tab. The Internal Correspondents transfer pane is used to specify the internal correspondents who are to receive alarms. The Available list displays all the internal correspondents defined in Alliance Access. To add an internal correspondent to the Selected list pane, double-click the Internal Correspondent in the Available column to move it to the Selected list pane. To remove an internal correspondent from the Selected list pane, double-click the Internal Correspondent in the Selected list pane to move it to the Available list pane. 5. Click the SNMP Servers tab. This tab allows you to specify one or more value pairs for the IP address, and port on which the SNMP Manager is listening for events. You can enter up to 16 destinations in the format <IP>:<port>. Each occurrence must be on a separate line. System Management Guide Configuring Event and Alarm Distribution 6. Click Modify . 18.2.7 Creating Distribution Lists To create distribution lists: 1. Run the System Management application. 2. From the View menu, select Distribution List. The Distribution List window appears, displaying the available distribution lists. 3. Either select New from the Distribution Lists menu, or highlight a distribution list and select New As from the Distribution Lists menu. The Distribution List Details window appears. 4. Complete the fields as required. For descriptions of these fields, see "Distribution List Details Window" on page 180. 5. Click Add. 18.2.8 Setting an Alarm for Background Treatment Overview For some applications, you may prefer to set certain types of alarm for background treatment. This means that these alarms are not distributed to operators as they occur, but are instead sent to the Event Journal as untreated alarms. Alarms are consigned to the background for the following reasons: • None of the operators specified in the alarm distribution list are currently signed on • The assigned operator for acting on the alarm decides to treat the alarm later by clicking Treat Later in the alarm pop-up window • The assigned operator for action did not treat the alarm, that is, they did not click Treated , before the alarm message window timed out. In such cases, the alarm is logged as untreated in the Event Journal. To set an alarm for background treatment: 15 July 2011 1. Run the System Management application. 2. From the View menu, select Event Distribution. The Event Distribution window appears, displaying the available event types. 3. Double-click the relevant event. The Event Distribution Details window appears. 4. Click Distribution and select either Journalise or Ignore. 5. With the Alarm option button, select True and the Alarm Info tab appears. To treat the alarm in the background, select False in the Distribute Alarm field. 6. From the Event Distribution menu, select Modify. 183 Alliance Access 7.0.20 18.3 Printing Reports Overview You can print reports of the information displayed in the Event Distribution and Distribution List windows. For more information, see "Printing Reports" on page 30. 18.4 Alarm Scripts Description An operator with permission to change security parameters can configure Alliance Access to collect all alarms and copy them to a file, from which they can be processed further. An alarm script is used to collect the alarms and store them in a file, and Alliance Access runs the script whenever an alarm occurs. Note An incorrect script may cause major problems on your system as processing an unusual number of alarms may cause a timing problem, and consequently, the system to hang. Instead of sending all alarms to a file, you may consider using event distribution to send specific alarms to a file. You can then use an external program to process this file. Alarm script The following example script shows where alarms are copied to a file alarm.out in the tmp directory: • On Windows: echo %* >> c:\temp\alarm.out • On UNIX: echo $@ >> /tmp/alarm.out Script and directory constraints The Path of Script File security parameter specifies the full pathname of the directory that contains the script to collect alarms. For more information about this parameter, see "Security Parameters" on page 102. The directory must be owned by the Alliance Administrator. On UNIX, the script must be compliant with the requirements of the UNIX exec system call, regarding the execution of an interpreter file 184 System Management Guide Configuring the Calendar and Scheduling Processes 19 Configuring the Calendar and Scheduling Processes Introduction This section describes how to configure a calendar using the Calendar application and how to schedule activities for various applications in Alliance Access. Note 19.1 During any period when the servers are running in housekeeping mode, no scheduled actions take place. Working with Calendars Introduction You can set up multiple calendars for a given year. This enables logical terminals to have their own calendar, which can be useful if the LTs are located in different countries, with different working days or public holidays. If multiple calendars have been defined, then the available calendars are displayed when the Calendar application is started. This list also shows which Calendar is currently set as the default. You can use the Calendar application to create additional calendars. You have to set up a calendar if you want users to be able to schedule Alliance Access processes to occur automatically. Alliance Access users can only schedule processes if the operator profiles allow them to do so. After you create your calendar, you must modify the appropriate profiles. For example, you may modify a profile so that operators can use the Message File application to schedule message archiving. Once you have created a calendar and modified the profiles, any users with the appropriate profiles can schedule processes. 19.1.1 Configuring a Calendar Overview The Calendar application enables you to create, modify, or remove calendars for the current year, the next year, or both. For each year in the calendar, you can assign one of the following day profiles: • Normal Working Day • Peak Working Day • Holiday • Weekend. Note 15 July 2011 If you modify a calendar year to include changes that affect the current day, then you must restart Alliance Access for your changes to take effect. Otherwise changes take effect automatically at midnight. 185 Alliance Access 7.0.20 19.1.2 Creating a New Calendar Introduction You create a calendar and assign a name to it from the Calendar application. You can create a calendar based on an existing one. In this case, all years defined for the existing calendar are also created in the new calendar. To create a calendar: 1. Run the Calendar application. 2. From the Calendar menu, select New. The following window appears: 3. Enter a unique name for the Calendar (maximum 20 alphanumeric characters) and then click New . Note A Year for the current year is automatically created in this calendar. To create a calendar based on an existing calendar: 1. Run the Calendar application. All currently defined calendars are displayed. 2. Select the calendar that you want to base your new calendar on, then select New As from the Calendar menu. 3. Enter a new, unique name for the Calendar (maximum 20 alphanumeric characters) and then click New . 19.1.3 Add a New Calendar Year To add a new calendar year: 186 1. Run the Calendar application. 2. If multiple calendars have been defined, then select the calendar for which you want to add a new calendar year, and select Open from the Calendar menu. System Management Guide Configuring the Calendar and Scheduling Processes The following window appears (with the year listed here if it has been defined): 3. From the Year menu, select New. The following window appears: 15 July 2011 4. Enter the year using the format (YYYY) in the Year field. Note that you can only add the current year or the next year. The Calendar Year Details window appears. 5. Click Details > > to expand the window. 187 Alliance Access 7.0.20 6. From the Year menu, select Add. 19.1.4 Removing a Year from a Calendar Introduction You can remove a Year from a Calendar if the Calendar is not defined as the default calendar, no schedule records are referencing it, and the Year to be removed is not the current year. Note During the startup of the Alliance Access servers, each Calendar is checked to see whether the current year has been defined. For each Calendar for which no current year is defined, an alarm event is generated. To remove a calendar year: 188 1. Run the Calendar application. 2. If multiple calendars have been defined, then select the calendar from which you want to remove a Year, and select Open from the Calendar menu. System Management Guide Configuring the Calendar and Scheduling Processes The following window appears (with the year listed here if it has been defined): 3. Select the Year that you want to remove and then select Remove from the Year menu. 19.1.5 Defining Weekends and Normal Days Overview By default, every day in the first calendar year that you create is given the day profile of Normal working day. If you want users to be able to schedule processes on a weekly basis, then you must redefine some days to have a day profile of weekend. If the current calendar year has already been created and you are now defining the next year, then by default any days defined as weekends in the current year are automatically defined as weekends in the new year. 19.1.5.1 How Alliance Access Defines System Attributes for Days Overview Depending on the profiles that you have defined for the days in a calendar, such as holidays and weekends, Alliance Access automatically assigns the following system attributes to the days: • First working day of month. This is assigned to the first day of the month that is not a Holiday or a Weekend. • Middle working day of month. This is assigned to the 16th of the month, or the next day that is not a Holiday or a Weekend. If you assign the profile Weekend to a day, Alliance Access automatically calculates the following system attributes: • First working day of week. This is assigned to the first day following a Weekend which is not a Holiday or a Weekend. • Last working day of week. This is assigned to the first day before a Weekend that is not a Holiday or a Weekend. 15 July 2011 189 Alliance Access 7.0.20 At the end of the year, a week can fall partly in one year and partly in the following year. In this case, the First working day of week refers to the first day in the current year following a Weekend which is not a Holiday or a Weekend. Similarly the Last working day of week refers to the last day in the current year before a Weekend that is not a Holiday or a Weekend. The following examples explain the scenario. Definitions: • WD = Working day • FWDW = First working day of week • LWDW = Last working day of week The last WD of December will be a LWDW and the first WD of January will be a FWDW. There are some configurations where a LWDW and FWDW fall on the same day. For example, if 31 December is a Monday or 2 January (assuming 1 January is a holiday) is a Friday, then in these cases, the day will be treated as FWDW. Example 1 If 31 December is a Wednesday and 1 January is not a holiday and Saturday, Sunday are weekends, then the days are considered as follows: • Mon = FWDW • Tue = Normal • Wed = LWDW • Thu = FWDW • Fri = LWDW Example 2 If 31 December is a Monday, 1 and 2 January (Tuesday and Wednesday) are holidays, then the days are considered as follows: • Mon = FWDW • Tue = Hol • Wed = Hol • Thur = FWDW • Fri = LWDW Example 3 If 31 December is Wednesday and 1 January (Thursday) is a holiday, then the days are considered as follows: • Mon = FWDW • Tue = Normal • Wed = LWDW • Thu = Hol 190 System Management Guide Configuring the Calendar and Scheduling Processes • Fri = FWDW Note If you make any changes to a calendar, then once the changes are saved, Alliance Access re-assigns the First and Last working day of the week and the First and Middle working day of the month accordingly. 19.1.5.2 Changing the Day Profile Overview You use the Redefine command to globally change the day profile for a given day throughout the year. For example, you can redefine every Friday as a Weekend, or every Saturday as a Normal working day. To redefine a day as a Weekend or as a Normal working day throughout the year: 1. From the Year menu, select Redefine. A menu lists all the days of the week. 2. Select the day whose profile you want to redefine. 3. Select the day profile. The following options exist: • Normal working day • Weekend. 19.1.5.3 Defining a Day as a Peak Working Day or Holiday Overview To complete your calendar customisation, you must specify which days are Peak working days and which are holidays. Note that a Weekend is automatically defined as a holiday and cannot be specified as a Peak working day. To define a day as a Peak Working Day or Holiday: 1. Use the forward and back buttons, located either side of the month name, to display the month that you want to work on. 2. Click the number of the day that you want to redefine. 3. In the Day Profile list, select one profile for the day. The following profiles exist: • Normal Working Day • Peak Working Day • Holiday The day is highlighted with the default colour that is assigned to that day profile. Note that the change applies only within the month currently displayed. 4. 15 July 2011 From the Year menu, select Add to save the changes. 191 Alliance Access 7.0.20 19.1.5.4 Assigning Colours to Weekends and Day Profiles To change the default colours that identify weekends and day profiles: 1. Click Show Legend to display the Color Legend box. Note that the changes to Hide Legend . 2. Click the colour that you want to change and select a new colour from the palette. 3. If you want to restore the default colours at any time, then click Default. 4. Click Hide Legend Show Legend button text to close the Color Legend box and apply the new colours. 19.1.6 Changing the Default Calendar Introduction If you have only one calendar defined, then it is automatically set as the default one. If you have more than one however, then you can select which one is to be used as the default. It is only possible to have one default calendar. Default calendars cannot be removed. If you have multiple calendars defined and you want to remove the calendar currently set as the default, then you must first change the default calendar. To change the default calendar: 1. Run the Calendar application. A list of all defined calendars appears. 2. Select the calendar that you want to set as the new default. The default calendar must contain an entry for the current year. 3. Select Set as Default from the Calendar menu. Note If you want the new default calendar to be activated immediately, then restart Alliance Access. Otherwise, the new default calendar will be activated on the next day. 19.1.7 Removing a Calendar To remove a calendar: 1. Run the Calendar application. A list of all defined calendars appears. 2. Select the calendar that you want to remove. Note You cannot remove a default calendar. If a calendar is removed, then any schedule records referencing this Calendar is updated so that their Calendar field is empty. 3. 192 Select Remove from the Calendar menu. System Management Guide Configuring the Calendar and Scheduling Processes 19.1.8 Printing Calendar Information Overview You can print different levels of information about calendars, or years within calendars, using the standard print options. The output produced depends on what you select. If you are printing from the list of defined Calendars: • If one or more Calendars are selected and you select to print "with details", then the details are printed for all the defined Years for each selected Calendar. • If one or more Calendars are selected and you select to print "without details", then a list of the defined Years is printed for each selected Calendar. If you are printing from the details of a given calendar: • If one or more Years are selected and you select to print "with details", then the details are printed for all the selected Years for the open Calendar. • If one or more Years are selected and you select to print "without details", then a list of the defined Years is printed for the open Calendar. 19.1.9 Modifying Operator Profiles to Enable Scheduling Overview Alliance Access users can schedule processes only if the operator profiles allow them to do so. Once you have customised your calendar, you must modify the profiles of the operators who use scheduling. Operator definitions which include these modified operator profiles require approval. Both the left security officer and the right security officer must approve the modifications. To modify an operator profile: 15 July 2011 1. Run the Security Definition application. The Operator - Security Definition window appears. 2. From the View menu, select Profile. The Profile - Security Definition window appears with a list of profiles available. 3. Double-click the profile that you want to modify, or select the profile and from the Profile menu, select Open. The Profile Details window appears. 193 Alliance Access 7.0.20 Note 4. When moving applications between the Available and Selected list boxes in the Profile Details window, you must use the transfer buttons. Do not doubleclick an application name to move it between boxes. Select the applications in which you want to enable scheduling by moving them from the Available list box to the Selected list box. Select from: • System Management • Event Journal • SWIFT Interface • SWIFTNet Interface • Message File 5. Select the application name in the Selected list box. The functions available in this application then appear in the Available list box for Functions. 6. Select functions by moving them from the Available list box to the Selected list box (for example Archive for the Event Journal). 7. Double-click the function name in the Available list box. The Security Definition Permission Details window appears. 8. Set the 1) Store schedule and 2) Modify operating mode fields to Yes. This is only possible with functions that can be scheduled (for example, archiving of the Event Journal). Note 9. Click OK . 10. From the Profile menu select Modify, to save the profile. 194 System Management Guide Configuring the Calendar and Scheduling Processes 11. Get the operator definitions for the modified profile approved by the right security officer and left security officer. 19.2 Scheduling Automated Processing Overview This section explains how processes can be scheduled to occur automatically. 19.2.1 Define a Schedule Overview Only users with the correct entitlements can schedule Alliance Access processes. The days on which actions can be scheduled are grouped into categories. To define a schedule: When you define a schedule for automating an Alliance Access process, you must: 1. Select a category to indicate when the action is going to occur. For example, you may want the action to occur every Business Month. 2. If there is more than one calendar defined (as in the SWIFT Interface application or SWIFTNet Interface application), then you must specify which calendar to use. Note 3. Only calendars that have the current year defined are available for selection. Specify the day and time when the action is to occur. The available types of day depend on the category that you have selected. For example, if you schedule the archiving of live messages to occur every Business Month, you may decide to archive twice each month: once on the First Working Day of Month and again on the Middle Working Day of Month. Note When scheduling processes from an Alliance Workstation, ensure that its time zone setting is the same as the time zone setting on the Alliance Access server. 19.2.2 How Scheduling Works Overview At the start of each day (midnight), Alliance Access checks the calendar and determines which day types apply to the current day. For example, today may be the First Working Day of Week and the First Working Day of Month. Alliance Access then checks to see whether any operations are scheduled for these day types. If an operation is scheduled, then Alliance Access carries it out at the specified time, unless the server is running in housekeeping mode. The schedule is also rebuilt after each restart of the server. If the restart occurs between the earliest and latest start times of an event, then that event is started automatically. 15 July 2011 195 Alliance Access 7.0.20 19.2.3 Processes that Can be Scheduled to Occur Automatically Overview You can schedule the following functions to occur automatically: • archive the Event Journal • archive the Message File • Back up the archives of the Event Journal and the Message File • remove archives • activate and de-activate the emission and reception profiles in the SWIFTNet Interface application • install CIF Update files • stop and restart the Alliance Access servers • Perform a FIN Select and logout from SWIFT • back up Alliance Access data to disk • import and export RMA authorisations (for more information, see the Relationship Management Application User Guide). For information about the permissions required to schedule these functions, see Appendix A, "Default Profiles". 19.2.4 Scheduling Event Journal Archiving Overview Depending on the volume of traffic that you handle, you may want to archive once daily, twice weekly, or even weekly. SWIFT recommends that you archive events regularly, for the following reasons: • Searching for events is faster if old events have been archived. SWIFT recommends that you keep event data in the Alliance Access database. However, you may keep less if required. • Events cannot be moved off the system unless they have been archived. • You risk running out of disk space if events are not archived and removed from the hard disk. • Archiving is faster if there are fewer events to archive. • Queries on archives are faster if the archives are smaller. To schedule Event Journal archiving: 196 1. Run the Event Journal application. If the Event Journal Search Criteria window appears, then close or move the window, so that the Event Journal window is visible. 2. From the File menu, select Archive. The Event Archive window appears. System Management Guide Configuring the Calendar and Scheduling Processes 3. Select Automatic from the Event archive operating mode list. The Event Archive Schedule Details window appears. 4. Type the number of days for which to keep events available in the database in the field Number of Traffic Days to keep in the Database (including current day). All other events are archived. For example, if you type 2, Alliance Access keeps today's events and the events from the previous day in the database, and archives all events with earlier dates. Note 5. Since events are archived for a full day, it is not possible to archive the events from the current day. In the Schedule Details/Schedule Category list, select a schedule. Select from: • Every day • Specific day • Business day • Business week • Business month. Note 6. Changing this field deletes any previously scheduled actions. Specify at least one action for the schedule. The following schedule details must be completed: • in the On Every field, select the type of day (the available choices depend on the Schedule Category selected). • in the Earliest Start field, specify the time (HH:MM:SS) at which the action is to occur. • in the Latest Start field, specify the latest time (HH:MM:SS) at which the action is to occur. The action is initiated if the earliest start time is missed and a restart of the system 15 July 2011 197 Alliance Access 7.0.20 occurs after the time specified in the Earliest Start field but before that in the Latest Start field. 7. To specify another action, select In use from the Second (or Third) Action list. 8. When you have completed the schedule details, click 9. Click Quit Store to save the settings. to quit the dialog box. 19.2.5 Scheduling Message File Archiving Overview SWIFT recommends that message file archiving is run on the last business day of the week, and the information retained for seven days. To schedule Message File archiving: 1. Run the Message File application. If the Message File Search Criteria window appears, then close or move the window, so that the Message File window is visible. 2. From the File menu, select Archive. The Message Archive window appears. 3. Select Automatic from the Message archive operating mode menu. The Message Archive Schedule Details window appears. 4. Type the number of days which you want to keep messages available in the database in the field Number of Traffic Days to keep in the Database (including current day). All other messages are archived (providing all messages for that day are complete). For example, if you type 3, Alliance Access keeps today's messages and the messages from the previous two days in the database, and archives all messages with earlier dates. If you type 1, the minimum value, then all messages older than today, are archived if they are completed (for that particular day). 5. From the Schedule Details/Schedule Category list, select a schedule. Select from: • Every day 198 System Management Guide Configuring the Calendar and Scheduling Processes • Specific day • Business day • Business week • Business month Changing this field deletes any previously scheduled actions. Note 6. Specify at least one action for the schedule. The following schedule details must be completed: • in the On Every field, select the type of day (the available choices depend on the Schedule Category selected). • in the Earliest Start field, specify the time (HH:MM:SS) at which the action is to occur. • in the Latest Start field, specify the latest time (HH:MM:SS) at which the action is to occur. The action is initiated if the earliest start time is missed and a restart of the system occurs after the time specified in the Earliest Start field but before that in the Latest Start field. Simultaneous backups of the same entity (messages or events) cannot be run. Therefore, you must take care when setting the earliest and latest times for different backups so that they do not coincide. Note 7. To specify another action, select In use from the Second (or Third) Action list. 8. When you have completed the schedule details, click 9. Click Quit Store to save the settings to quit the dialog box. 19.2.6 Scheduling Archive Backups Overview Using the System Management application, you can define a schedule for Alliance Access to create backups of the following archives: • Event Journal archive • Message File archive Newly stored schedules are accepted by the system within one minute after its creation, provided that: • the servers are running in Operational mode • a calendar for the current year has been defined Note • You cannot schedule the restoration of a backup. • You cannot create backups of archives that were created using Alliance Access 6.0 or earlier. 15 July 2011 199 Alliance Access 7.0.20 Location of archive backup files The following are the default locations where Alliance Access stores archive backup files: • Event Journal archive: <software dir>\usrdata\backup\eja • Message archive: <software dir>\usrdata\backup\mfa Where <software dir> is the directory in which Alliance Access is installed. In the schedule, the path names always refer to a location on server. To schedule an archive backup: 1. Run the System Management application. 2. From the File menu, select Backup. The Backup Alliance window appears. 3. Click one of the following tabs: • Journal Archive • Message Archive 4. In the Backup operating mode field, select Automatic from the list. 5. The Backup Directory field specifies the location where Alliance Access stores the backup file. If required, click ... to specify a different location. Tip 6. If you intend to copy the backup to tape or a hard disk, then make a note of this directory path for future reference. In the Schedule Category list, select one of the following schedules: • Every day • Specific day • Business day 200 System Management Guide Configuring the Calendar and Scheduling Processes • Business week • Business month Changing this field deletes any previously scheduled actions. Note 7. Specify at least one action for the schedule, as follows: Field Action On Every Select the type of day. The available choices depend on the Schedule Category that you selected. Earliest Start Specify the time (HH:MM:SS) at which the action is to occur. Latest Start Specify the latest time (HH:MM:SS) at which the action is to occur if the Earliest Start time is missed. If Alliance Access restarts after the time specified in the Earliest Start field but before the time specified in the Latest Start field, then Alliance Access performs the scheduled action. Mode Specify the action (all archives except for Database), as follows: • Backup, to back up the archive to the specified path. • Remove, to remove the archive (no backup taken). • Backup & Remove, to back up the archive and then remove the original. Simultaneous backups of the same entity (messages or events) cannot be run. Therefore, you must take care when setting the Earliest Start and Latest Start times for different backups so that they do not coincide. Note 8. To specify another action, select In use from the Second (or Third) Action list. 9. When you have completed the schedule details, click 10. Click Quit Store to save the settings. to quit the dialog box. A scheduled backup of any of the archive types (messages or events) always backs up all available archives (with the status "Ready") of that type defined at the moment the backup process starts. If the Mode is Backup & Remove, then archives are removed from the system after being successfully backed up. If an archive is being read by an application whilst a backup procedure begins, then the backup is performed but the archive is not deleted (an error message is raised but not displayed). If you do not remove the archive, then the archive stays in the database and its status is changed to Backed Up. Therefore, it is not backed up at a later stage. This prevents the same archives being backed up at every scheduled backup. If the Mode is Backup & Remove, then the archive is removed from the system after Alliance Access creates the backup successfully and the same conditions apply as for manual archive backups. The Backup/Restore application creates backups of archives according to a schedule. If a backup or restore action is running when the backup is started, then Alliance Access does not create the backup. It creates an event for this backup failure. 15 July 2011 201 Alliance Access 7.0.20 19.2.7 Scheduling Database Backups Overview Using the System Management application, you can define a schedule to create backups of the Alliance Access database. Alliance Access accepts newly stored schedules within one minute of their being stored, if: • the servers are in Operational mode • a calendar for the current year has been defined. Note You cannot schedule the restoration of a backup. To schedule a database backup 1. Run the System Management application. 2. From the File menu, select Backup. The Backup Alliance window appears. 3. Click the Database tab. 4. In the Backup operating mode field, select Automatic. 5. The Backup Directory field specifies the location where Alliance Access stores the backup file. If required, click ... to specify a different location. Tip 6. If you intend to copy the backup to tape or a hard disk, then make a note of this directory path for future reference. In the Schedule Category list, select one of the following schedules: • Every day • Specific day • Business day 202 System Management Guide Configuring the Calendar and Scheduling Processes • Business week • Business month Changing this field deletes any previously scheduled actions. Note 7. Specify at least one action for the schedule, as follows: Field Action On Every Select the type of day. The available choices depend on the Schedule Category that you selected. Earliest Start Specify the time (HH:MM:SS) at which the action is to occur. Latest Start Specify the latest time (HH:MM:SS) at which the action is to occur if the Earliest Start time is missed. If Alliance Access restarts after the time specified in the Earliest Start field but before the time specified in the Latest Start field, then Alliance Access performs the scheduled action. Because simultaneous backups cannot be run, take care when setting the Earliest Start and Latest Start times for different backups to ensure that they do not coincide. Note 8. To specify another action, select In use from the Second (or Third) Action list. 9. When you have completed the schedule details, click 10. Click Quit Store to save the settings. to quit the dialog box. 19.2.8 Scheduling Alliance Access Servers to Stop Overview There are no restrictions on how often Alliance Access can be shut down. To schedule the Alliance Access servers to stop at specific times: 15 July 2011 1. Run the System Management application. 2. From the File menu, select Stop Alliance. 3. Select Automatic from the Stop operating mode list. This displays the System Management - Stop Alliance window, where you can specify details of how you want to stop Alliance Access automatically. 203 Alliance Access 7.0.20 4. Select a category in the Schedule Category list. Select from: • Every day • Specific day • Business day • Business week Note 5. Changing this field deletes any previously scheduled actions. Specify at least one action for the schedule. The following schedule details must be completed: • in the On Every field, select the type of day (the available choices depend on the Schedule Category option selected). • in the at field, specify the time (HH:MM:SS) at which the action is to occur. 6. To specify another action, select In use from the Second (or Third) Action list. 7. When you have completed the schedule details, click click Quit to quit the dialog box. Store to save the settings, and then 19.2.9 Scheduling Alliance Access Servers to Restart To schedule the Alliance Access servers to restart at specific times: 1. Run the System Management application. 2. From the File menu, select Restart Alliance. 3. In the Restart mode field, select the mode in which you want Alliance Access to restart. The options are: • Housekeeping, to restart Alliance Access in housekeeping mode • Operational, to restart Alliance Access in operational mode. 204 System Management Guide Configuring the Calendar and Scheduling Processes 4. Select Automatic from the Restart operating mode list. This displays the System Management - Restart Alliance window, where you can specify details of how you want to automate the restart. 5. Select a category from the Schedule Category list. The choices are: • Every day • Specific day • Business day • Business week Note 6. Changing this field deletes any previously scheduled actions. Specify at least one action for the schedule. The following schedule details must be completed: • in the On Every field, select the type of day (the available choices depend on the Schedule Category list option selected). • in the at field, specify the time (HH:MM:SS) at which the action is to occur. 7. To specify another action, select In use from the Second (or Third) Action list. 8. When you have completed the schedule details, click click Quit to quit the dialog box. Store to save the settings, and then 19.2.10 Scheduling FIN Select or Logout from SWIFT Overview This section explains how to schedule FIN Select or Logout from SWIFT to occur automatically. 19.2.10.1 Scheduling FIN Select or Logout from SWIFT Operation Mode In Alliance Access, there are two modes in which a logical terminal can operate: Manual and Automatic. The Automatic mode enables you to schedule operations. When a logical terminal is operating in Manual mode, none of the scheduled operations are activated. 15 July 2011 205 Alliance Access 7.0.20 If the logical terminal is operating in manual mode, and if one or more of the following conditions are true, then Alliance Access does not change the operational mode of the logical terminal to automatic: • The logical terminal has no connection assigned to it currently • Alliance Access has no calendar defined for the current year • No scheduled actions are defined for the logical terminal • No scheduled action is defined to occur at 00:01 am for each type of day for which at least one action has been defined Note The scheduled action at 00:01 am is mandatory for recovery reasons. You can either define a real action for that time or use the same action as the last action of the previous day. When you schedule Specific Days, make sure that an entry exists for 00:01 for every day that you want the Logical Terminal to be Selected. • The logical terminal is in a session and the connection that the logical terminal is using is currently suspended. Note If a logical terminal is running in automatic mode and an operator manually tries to log on, log off, select, or quit it, then the logical terminal switches back to manual mode. This happens even if the operator does not have specific permissions to change the mode of operation for a logical terminal. However, the system warns the operator and requires a confirmation before continuing. To automate FIN Select or Logout from SWIFT 1. Run the SWIFT Interface application. 2. If the Logical Terminal list pane is not shown, then select Logical Terminal from the View menu. The Logical Terminal - SWIFT Interface main window appears: 206 3. Double-click the logical terminal for which you want to make a schedule. The Logical Terminal Details window appears, with tabs for information for the logical terminal that you selected. 4. Click the Schedule Details tab. System Management Guide Configuring the Calendar and Scheduling Processes 5. Select a category in the Category field list. The choices available are: • Every day • Specific day • Business day • Business week Note 6. From the Calendar: drop-down list, select the calendar to use. 7. From the Action menu, select New. The Action Details window appears. Define at least one action for the schedule. 8. In the Action Id field type an ID to the Action for example, "1". 9. In the On Every field, select the type of day from the list. The available choices depend on the Category selected. Note 15 July 2011 Changing this field deletes any previously scheduled actions. The On Every field is disabled if you selected Every Day in the Category field of the Logical Terminal Details screen. 207 Alliance Access 7.0.20 10. In the At field, type a time for the schedule to run. 11. In the Do field, select an action. Select from: • Select Input, to perform a login to APC, Select FIN and send messages. • Select Output, to perform a login to APC, Select FIN and receive messages. • Select Input/Output, to perform a login to APC, Select FIN and send and receive messages. When you select Select Output or Select Input/Output, a transfer list box appears where you can select the delivery subsets to be assigned to the logical terminal. • Logout, to quit FIN and log out from APC. 12. From the Action menu, select Add. 13. Close the Action Details window. Note Alliance Access automatically applies the scheduled state, even after a line failure. 14. Repeat the previous steps until all actions are defined. 15. From the Logical Terminal menu, select Automatic Mode. 19.2.11 Scheduling Emission and Reception Profile Actions Introduction Once you have defined your emission and reception profiles, you can set up schedules by creating actions using the SWIFTNet Interface application Emission Profile and Reception Profile Schedule tabs. Within the schedules, an action can be added through the Action Details window. 19.2.11.1 Defining a Schedule for an Emission Profile To define a schedule for an emission profile: 208 1. Run the SWIFTNet Interface application. 2. Ensure that the Emission Profile View appears. If the Emission Profile View window is not shown, then select Emission Profile from the View menu. The Emission Profile View displays a list of the currently defined emission profiles. 3. Select the emission profile for which you want to create a schedule and actions and then Open from the Emission Profile menu. The Emission Profile Details window opens. 4. Select the Schedule Details tab. System Management Guide Configuring the Calendar and Scheduling Processes The following window appears: 5. From the Category field, select a category for the schedule. The choices available are: • Every day • Specific day • Business day • Business week. 6. From the Calendar: drop-down list, select the calendar to be used. 7. Select Modify in the Emission Profile window. 8. Next you must create actions. From the Actions menu, select New (if you have existing schedules, you can highlight an existing schedule shown in the Schedule Details tab and from the Action menu select New As to base the new schedule on the existing one). The Action Details window appears: 9. In the Action Id field, type a numeric identifier of up to nine digits for the schedule. 10. In the On Every field, select the type of day on which you want the scheduled action to occur. The choices available depend on the selection that you made in the Category field of the Schedule Details tab. Note If you select Every Day in the Category field, then the On Every field in the Action Details window is disabled. 11. In the At field, type the time at which you want the action to occur. 12. In the Do field, select the action that you want to occur. 15 July 2011 209 Alliance Access 7.0.20 Choices are: • Activate, to activate the Emission Profile. • De-activate, to deactivate the Emission Profile. 13. From the Action menu, select Add to save your schedule. 14. From the Emission Profile menu, select Automatic Mode. Note If you want to modify a schedule, then double-click the action in the Schedule Details tab to display the Action Details window. You can modify all fields except for the Action Id field. Select Modify from the Action menu to save your modifications. If you want to delete a scheduled action, then double-click the action in the Schedule Details tab to display the Action Details window. Then select Remove from the Action menu to save your modifications. 19.2.11.2 Defining a Schedule for a Reception Profile To define a schedule for a reception profile: 1. Run the SWIFTNet Interface application. 2. Ensure that the Reception Profile View appears. If the Reception Profile View window is not shown, then select Reception Profile from the View menu. The Reception Profile View displays a list of the currently defined reception profiles. 3. Select the reception profile for which you want to create a schedule and actions and then Open from the Reception Profile menu. The Reception Profile Details window opens. 4. Select the Schedule Details tab. 5. From the Category field, select a category for the schedule. The choices available are: • Every day • Specific day • Business day • Business week. 6. 210 From the Calendar: drop-down list, select the calendar to be used. System Management Guide Configuring the Calendar and Scheduling Processes 7. Select Modify in the Emission Profile window. 8. Next you must create actions. From the Actions menu, select New (if you have existing schedules, then you can highlight an existing schedule shown in the Schedule Details tab and from the Action menu select New As to base the new schedule on the existing one). The Action Details window appears: 9. In the Action Id field, type a numerical identification of up to nine digits for the schedule. 10. In the On Every field, select the type of day on which you want the scheduled action to occur. The choices available depend on the selection that you made in the Category field of the Schedule Details tab. Note If you select Every Day in the Category field, then the On Every field in the Action Details windows is disabled. 11. In the At field, type the time at which you want the action to occur. 12. In the Do field, select the action that you want to occur. Choices are: • Activate, to activate the Reception Profile. • Deactivate, to deactivate the Reception Profile. 13. From the Action menu, select Add to save your schedule. 14. From the Reception Profile menu, select Automatic Mode. Note If you want to modify a schedule, then double-click the schedule in the Schedule Details tab to display the Action Details window. You can modify all fields except for the Action Id field. Select Modify from the Action menu to save your modifications. If you want to delete a scheduled action, then double-click the schedule in the Schedule Details tab to display the Action Details window. Then select Remove from the Action menu to save your modifications. 19.2.12 Scheduling Installation of the Bank Update File Purpose You can schedule the installation of the Bank Update File by running the Update from BIC command in the Correspondent Info application. You can schedule the update while Alliance Access is running in Housekeeping or in Operational mode. The Bank Update File is installed at the next scheduled time, while the Alliance Access server is running in Operational mode. 15 July 2011 211 Alliance Access 7.0.20 Prerequisite The Bank Update File must be located in the following directory: • Windows - <Alliance_Install_Dir>\data\UpdateBIC • UNIX - $ALLIANCE/data/UpdateBIC For more information about putting the Bank Update File in this directory, see "Download an Alliance Bank File" on page 42. To schedule installation of the Bank Update File: 1. Run the Correspondent Info application. 2. Select Update from BIC from the File menu. The Update from BIC file window appears, which resembles the following: 3. Select BIC update file, if it is not selected already. 4. From the Update Operating mode field, select Automatic. The Schedule Details panel appears in the Update from BIC file window: 5. 212 Enter the scheduling details, that is, when you want the operation to be performed. Click Store . System Management Guide Configuring the Calendar and Scheduling Processes If an update file is available at the location specified in File location, then the file is installed at the scheduled time. The servers do not have to be restarted after the file is installed. 19.2.13 Scheduling Database Recovery Backups Purpose You can schedule a database recovery backup. To do this, option 14:DATABASE RECOVERY must be licensed, and the function "Manage Rec Backup" of the System Management application must be included in an operator profile. The Recovery Mode must be active before a Recovery Backup can be scheduled. For information on how to activate the Recovery Mode, see the Installation and Administration Guide. To schedule the creation of database recovery backups: 1. Run the System Management application. 2. From the File menu, select Manage Recovery Backups. The Recovery Backup Management window appears. 3. Specify the type of event which triggers a database recovery backup in the Recovery Backup Trigger field. Select: • Thresholds, to create a recovery backup when the total size of the archived redo log files or of the incremental backups reach predefined values. To define thresholds, see "Thresholds settings" on page 214. • Time Schedule, to create a recovery backup at predefined moments. To define time schedules, see "Time Schedule settings" on page 214. 15 July 2011 4. The Recovery Mode field is a read-only field that displays the current value of the Recovery Mode: Activated or Deactivated. 5. The Recovery Backup Directory field is a read-only field that displays the directory where the database recovery backups are created. 6. Select the Include Archive Backups check box if you want backups of archives (messages or journal events) to be included in the generated recovery backups. By default, these archive backups are not included in the recovery backups. 213 Alliance Access 7.0.20 7. Select the Compress Recovery Backups check box if you want created recovery backups to be compressed, which reduces the disk space required for their storage. 8. When you have completed the Thresholds or Time Schedule settings, click your settings. Store to save Thresholds settings When you select Thresholds in the Recovery Backup Trigger field, the following field settings are available. Field Action Active From and To Specify the period of the day (hour, minute, and second) during which recovery backups may be triggered. The default values are 02:00:00 and 06:00:00. Archived Logs Total Size (MB) Specify a threshold (in MB) for the total size of the archived redo log files. If the size of the archived redo logs is greater than this value, then the total size of the incremental backups is compared with the size of the latest full database backup. If the total size of the incremental backups is greater, then a full backup is taken. If not, the total size of the incremental backups is compared with its threshold (see Incremental Backups Total Size parameter). The default value of this parameter is 1024. The value must be included in the range [64, 999999]. Incremental Backups Total Size (MB) Specify a threshold (in MB) for the total size of the existing incremental backups. If the size of the existing incremental backups is less than this value, then an incremental backup is taken. If it is greater, then a full backup is taken. This parameter is used to trigger an incremental or a full backup. It is not used to control the maximum size of the total incremental backups, which can be greater than this specified threshold. The default value of this parameter is 2048. The value must be included in the range [64, 999999]. Time Schedule settings When you select Time Schedule in the Recovery Backup Trigger field, the following field settings are available. Field Action Schedule Category Select one of the following schedules: Every day, Business day, Business Week, Business month, Specific day. Action Possible values are In use or Not in use. At least one action must be In use, and one of the In use action must have Full Backup selected in the Mode field. 214 On Every Select the type of day. Earliest Start time Specify the time (HH:MM:SS) at which the recovery backup is to start. Latest Start time Specify the latest time (HH:MM:SS) at which a recovery backup is to start if the Earliest Start time is missed. Mode Specify which type of recovery backup must be created: Full Backup or Incremental Backup. System Management Guide Updating the Correspondent Information File 20 Updating the Correspondent Information File Introduction This section describes how to use the Correspondent Information File application to create and maintain details of correspondents, countries, currencies and aliases in a Correspondent Information File. 20.1 The Correspondent Information File Overview You use the Correspondent Information File application (CIFA) to create and maintain details of correspondents in a Correspondent Information File (CIF). In Alliance Access, a correspondent can be an institution, department or individual which Alliance Access can communicate with through a network. By using the CIF to save details of the correspondents who you communicate with, you make it easier to prepare messages for the correspondents and process messages received from them. Updating the Correspondent Information File After installing Alliance Access, you must use CIFA to install the Alliance Bank File. The Bank File contains the names and addresses of BIC Institutions, the standard ISO country codes, and the standard ISO currency codes. When the Bank File is installed, Alliance Access imports details from it to the CIF. When an operator creates a message for a correspondent, Alliance Access takes values from the correspondent record in the CIF and includes them as default values in the message. This helps to speed up message creation and reduce errors in message entry. SWIFT distributes an updated version of the Bank File on a regular basis. Whenever you receive a new version of the Bank File, you must update the CIF by importing the new information. For information about installing a Bank File, see "Installing the SWIFT Alliance Bank File" on page 39. Within each correspondent, country and currency record in the CIF, you can specify whether the record is to be updated automatically when you install the Bank File. Although most of the details in the CIF are imported from the Bank File, you can also add details to the CIF manually. Groups of correspondents CIFA includes features that make it easy to create and maintain groups of related correspondents. For example, if a department is at the same address as the institution to which it belongs, you can specify that the department correspondent inherits its address details from the existing institution correspondent. If the institution and department move to a new address, then you only have to change the address of the institution correspondent. The department correspondent inherits the changed address automatically. You can also create and maintain aliases (alternative names) for a correspondent or for a group of correspondents in the CIF. When an operator creates a message, the operator can specify that the message is sent to an alias. If the alias is for a group of correspondents, then this enables the operator to send a single non-financial message to a group of correspondents. 15 July 2011 215 Alliance Access 7.0.20 20.2 Running the Correspondent Information File Application Overview You use the Correspondent Information File application to create and maintain details of correspondents in the CIF. To run the Correspondent Information File application: • Double-click the Correspondent Info icon in the Access Control window. The Correspondent File - Search Criteria window appears so that you can search for and list correspondents. For details of how to search for correspondents, see "Searching for Correspondents" on page 220. 20.3 Displaying Records Overview The Correspondent Information File contains detailed records for: • Correspondents • Aliases • Currencies • Countries. You can use the Correspondent File window to display a list of one type of these records at a time. 20.3.1 Displaying Correspondents Overview Each time that you run the Correspondent Information File application, the Correspondent File - Search Criteria dialog box appears so that you can search for and list correspondents. For details, see "Searching for Correspondents" on page 220. 216 System Management Guide Updating the Correspondent Information File To display correspondents: 1. Run the Correspondent Information File application from the Access Control window. 2. Select Correspondent from the View menu. If you searched for correspondents previously and have not closed CIFA since then, select Correspondent from the View menu. The correspondents are listed in the Correspondent File window. 20.3.2 Displaying Aliases To display aliases: 1. Run the Correspondent Information File application from the Access Control window. 2. Select Alias from the View menu. 3. There can be two different results after you select Alias. If you are viewing aliases for the first time since running CIFA, then the Correspondent File - Search Criteria dialog box appears so that you can search for and list aliases. For more information about how to search for aliases, see "Searching for Aliases" on page 236. Alternatively, if you searched for aliases previously and have not closed CIFA since then, after you select Alias from the View menu, the aliases are listed in the Correspondent File window. 15 July 2011 217 Alliance Access 7.0.20 20.3.3 Displaying Currencies To display currencies: 1. Run the Correspondent Information File application from the Access Control window. 2. Select Currency from the View menu. All the currency records in the CIF are listed in the Correspondent File window. The list consists of all the records imported from the Bank File, plus any new currency records that have been added manually. Field descriptions • Code The unique three-character ISO standard currency code, as recorded in the CIF. • Name The full name of the currency, as recorded in the CIF. 20.3.4 Displaying Countries To display countries: 218 1. Run the Correspondent Information File application from the Access Control window. 2. Select Country from the View menu. All the country records in the CIF are listed in the Correspondent File window. System Management Guide Updating the Correspondent Information File The list consists of all the records imported from the Bank File, plus any new country records that have been added manually. You can make the View options that you select the default settings for the Correspondent Information File application. When you select Save Settings from the File menu, all your current settings are saved. From then on, whenever you start CIFA and view this window, Alliance Access uses the saved settings when displaying information. Field descriptions • Code The unique two-character ISO standard country code, as recorded in the CIF. • Name The full name of the country, as recorded in the CIF. 20.3.5 Displaying Details Overview The Correspondent Information File application main window only displays summary details for each correspondent, country, currency and alias. If necessary, you can display more detailed information about a specific correspondent, country, currency or alias. To display further details for a CIF record: 1. If the type of records that interest you are not currently displayed within the Correspondent File window, then select Correspondent, Country, Currency or Alias from the View menu, as appropriate. 2. Double-click the correspondent, country, currency or alias for which you want to display details. If you select: • a correspondent, the Correspondent Details window opens. For details of the fields in this window, see "Creating Correspondents" • an alias, the Alias Details window opens. For details of the fields in this window, see "Creating Aliases" on page 237 15 July 2011 219 Alliance Access 7.0.20 • a currency, the Currency Details window opens. For more information about the fields in this window, see "Creating Currency Records" on page 239 • a country, the Country Details window opens. For more information about the fields in this window, see "Creating Country Records" on page 241. 20.4 Searching for Correspondents Overview You use the Correspondent File - Search Criteria dialog box to specify the search criteria for correspondents. Note You can also search for correspondents when you are create an alias. For details, see "Searching for Aliases" on page 236. 20.4.1 Opening the Search Criteria Dialog Box To search for correspondents: • Double-click the Correspondent Info icon in the Access Control window. If the Correspondent Information File application is already running, then select Search from the Correspondent menu. The Correspondent File - Search Criteria window appears. The window contains several tabs. You use the fields within the tabs to define your search criteria. The Correspondent File window has no correspondents listed in it until you use the Correspondent File - Search Criteria dialog box to run a search. To do this you must specify search criteria, as described in "Specifying Search Criteria" on page 220. 20.4.2 Specifying Search Criteria Overview To list all correspondents in the Correspondent Information File, click Search . However, it is likely that you will want to make your search more specific. To do this, you can enter all or some of the following search criteria described. 220 System Management Guide Updating the Correspondent Information File You can search on combinations of criteria such as: • the type of correspondent - a correspondent can be an Institution, a department within an Institution, or even a named individual within a department • the correspondent status • the application details defined for the correspondent. The tabs are used to specify the criteria. If, while you are selecting these criteria, you decide to start again, then click Clear . After entering the search criteria, click Search to start the search. After the search begins, the Correspondent Search Dialog window closes. The correspondents meeting all your search criteria appear in the window from which you started the search. You can specify the details for the correspondents for which you are searching by completing the fields in one or more of the Correspondent, Definition, Status, and Integrated Application tabs in the Correspondent File - Search Criteria dialog box. In several fields, you can use the following "wildcard" characters: • "_" to replace one unknown character in a string • "%" to replace zero, one or more sequential unknown characters in a string. 20.4.2.1 Completing the Correspondent Tab To complete the Correspondent tab: 1. Click the Correspondent tab. 2. Click Correspondent Type. Select: • Any to search for correspondents of any correspondent type • Institution to search only for correspondents which are Institutions • Department to search only for correspondents which are Departments • Individual to search only for correspondents who are Individuals. 3. 15 July 2011 In the Institution field, type the BIC-11 address of the Institution to search for. Use of wild cards is allowed. 221 Alliance Access 7.0.20 4. If the Correspondent Type is set to Any, Department or Individual, then the Department field appears. In this field, enter the name of the department within the Institution that you are searching for. Use of wild cards is allowed. 5. If the Correspondent Type is set to Any or Individual, then the Last Name and First Name fields appear. In the Last Name field, enter the last name of the individual who you are searching for, and in the First Name field, enter the individual's first name. Use of wild cards is allowed. 20.4.2.2 Completing the Definition Tab To complete the Definition tab: 1. Click the Definition tab. 2. From the Correspondent Definition drop-down menu, select: • Any to search for correspondents whether they are internal or external. • Internal to search only for internal correspondents. These are correspondents owned by the Institution. • External to search only for external correspondents. These are correspondents not owned by the Institution. 3. In the Institution Name field, enter the full name of the institution. Use of wild cards is allowed. 4. In the Branch field, enter the full name of the branch. Use of wild cards is allowed. 5. In the City Name field, enter the name of the city in which the correspondent is located. Use of wild cards is allowed. 6. In the Country Code field, enter the ISO standard country code for the country in which the correspondent is based. Use of wild cards is allowed. 20.4.2.3 Completing the Status Tab To complete the Status tab: 1. 222 Click the Status tab. System Management Guide Updating the Correspondent Information File 2. Click Correspondent Status. Select: • Any to search for correspondents of any status • Active to search only for correspondents with an Active status • Inactive to search only for correspondents with an Inactive status. You cannot send a message using the SWIFT network to an inactive correspondent. 3. In the Modified Since field, enter a date. Only correspondent records which have been modified since this date are included in the search. 4. You can now specify the application details for which you are searching, using the Integrated Application tab. Different correspondents use different applications, and have different details defined in the CIF. 20.4.2.4 Completing the Integrated Application Tab To specify the defined application in the search: 1. Click the Integrated Application tab. 2. Click Defined Application. Select Any to search for correspondents with any or no defined applications. 15 July 2011 223 Alliance Access 7.0.20 Select: • Any to search for correspondents with any or no defined applications. • APPLI to search only for correspondents that have APPLI as one of their defined applications. APPLI is the Alliance application interface to external message partners (such as back-office banking systems). Go to "Specifying the Details when APPLI is Selected" on page 224 to specify the details when APPLI is selected. 3. After entering the search criteria, click Search to start the search. 20.4.2.5 Specifying the Details when APPLI is Selected Overview In the Integrated Application tab, if you select APPLI to search only for correspondents that have APPLI as one of their defined applications, additional fields appear so that you enter specific search criteria for your selected application. To specify the details when APPLI is selected: 1. If you select APPLI, then the Integrated Application tab changes to show new fields. 2. Click Exit Point and select the Alliance Access exit point to which any messages for the correspondent are routed. 20.4.3 Listing Search Results Overview When a search is complete, the results appear in the Correspondent File window. For a description of the fields displayed in this window, see "Correspondent File Window Search Results" on page 225. The window shows details of the correspondent records from the CIF. You can change the amount of information that appears for each correspondent by selecting View from the Correspondent menu and clicking a selection. You can make the View options that you select the default settings for this window by choosing Save Current Settings from the File menu. From then on, whenever you view this window, Alliance Access uses the saved view options when displaying information. 224 System Management Guide Updating the Correspondent Information File 20.5 Correspondent File Window - Search Results Description When a search is complete, the results appear in the Correspondent File window. The window shows details of the correspondent records from the CIF. Example of Correspondent File window Field descriptions Institution The BIC-11 address of the Institution. The BIC-8 destination address is followed by either a specific 3-character branch code or by a default branch code of "XXX". Department If the correspondent is a Department or Individual, this is the name of the Department within the Institution. Otherwise, it is blank. Last Name If the correspondent is an Individual, this is the last name of the Individual. Otherwise, it is blank. First Name If the correspondent is an Individual, this is the first name of the Individual. Otherwise, it is blank. Status The status of the correspondent. This can be active or inactive. You can send a message to an active correspondent. You cannot send a message to an inactive correspondent using the SWIFT network. Type The correspondent type. This can be either an Institution, a Department, or an Individual. City Name The name of the city in which the correspondent is located. 15 July 2011 225 Alliance Access 7.0.20 Institution Name The name of the Institution. Country The 2-character ISO standard code for the country in which the correspondent is based - the same as characters 5 and 6 of the BIC-11 address in the Institution field. 20.6 Creating Correspondent Records Overview The records in the BIC are institutions. You can use CIFA to define departments and individuals within these institutions. In the CIF, the majority of the correspondent records for institutions are imported from the Bank File. However, if you are dealing with a new institution, and you do not want to wait for the next update of the Bank File, you can use CIFA to add a new institution record to the CIF manually. You can also use CIFA to define departments and individuals within institutions, and to create internal correspondents . When you create a correspondent record, you define: • the type of correspondent, which can be an Institution, Department or Individual • general information, such as the correspondent's address, whether the record is to be updated automatically when a new Bank File is loaded, and so on • which of the correspondent's Alliance Access integrated applications have their details defined in the correspondent record • the preferred network application Alliance Access must use when sending messages to the correspondent Note If the SWIFTNet Interface is present, then SWIFTNet will be added as the preferred network to all correspondents, except for internal correspondents and the BIC1 correspondents. • details of the correspondent's Alliance Access integrated applications. When you create a correspondent, you can specify that some details are inherited (copied) from an existing correspondent with which the new correspondent is associated. For detailed information and examples, see "Parent and Child Correspondents" on page 232. 20.6.1 Creating Correspondents To create a correspondent record in the CIF: 1. If correspondents are not displayed in the Correspondent File window, then select Correspondent from the View menu. 2. Either select New from the Correspondent menu or if you want the new correspondent to be based on an existing correspondent, highlight the existing correspondent and select New As from the Correspondent menu. The Correspondent Details - New window appears. 226 System Management Guide Updating the Correspondent Information File Complete the Correspondent Profile tab: 1. Click the Correspondent Profile tab. 2. In the Institution field, enter the BIC-11 address of the Institution. Enter the BIC-8 destination address followed by either a specific 3-character branch code or by a default branch code of "XXX". Special characters are not allowed in this field. 3. Click Correspondent Type. Select: • Institution if the correspondent is an institution • Department if the correspondent is a department • Individual if the correspondent is an individual. 15 July 2011 4. If the Correspondent Type is set to Department or Individual, then the Department field appears. Enter the name of the department in this field (special characters are not allowed). 5. If the Correspondent Type is set to Individual, then the Last Name and First Name fields appear. Enter the individual's last name in the Last Name field, and first name in the First Name field (special characters are not allowed). 6. Optionally, in the Sub Type field, enter a more specific description of the correspondent type. For example, "BANK" (special characters are not allowed). 7. Click Profile to specify whether the correspondent profile is specific to this correspondent or is inherited from an existing correspondent. The available choices depend on the correspondent type. 227 Alliance Access 7.0.20 Select: • Specific if the profile is specific to the correspondent and is not inherited from a parent correspondent • Same as Department if the correspondent is an Individual for whom the associated Department correspondent exists, and if the correspondent inherits its profile from that Department • Same as Institution if the correspondent is a Department for whom the associate Institution correspondent exists, and if the correspondent inherits its profile from that Institution. 8. Complete the fields in the Details pane. You may use special characters in these fields: • In the Institution field, enter the full name of the institution • In the Branch Info field, enter the full name of the branch • In the City Name field, enter the name of the city in which the correspondent is located • The Country field shows the ISO standard country code for the country in which the correspondent is based. This is characters 5 and 6 of the BIC-11 address in the Institution field. This is a display-only field. • In the Address field, enter the address of the correspondent. • In the Location field, enter the location of the correspondent. • In the POB Number field, enter the Post Office Box number of the correspondent. • In the POB Location field, enter the location of the Post Office Box. Complete the Other tab: 1. 228 Click the Other tab. System Management Guide Updating the Correspondent Information File 2. Click Update on BIC Load. Select: • No if you do not want the correspondent record to be updated when a new Bank File is loaded. This means that if the Bank File shows that the correspondent must be modified, the CIF record is not modified. If the Bank File shows that the correspondent must be deleted, then the CIF record is not deleted, but SWIFT is removed from the list of Preferred Networks for the correspondent. By default, any new manually created record has this option set to No. • Yes if you want the correspondent record to be updated when a new Bank File is loaded. The CIF record may be modified or deleted as a result of the update. 3. Click Correspondent Definition. Select: • Internal if the correspondent is owned by the Institution Note To use the created Internal Correspondent in the Message Creation application, you must sign off and sign on from the Alliance workstation. • External if the correspondent is not owned by the Institution. Once you add a new correspondent to the CIF, you cannot change its definition. 15 July 2011 4. The Correspondent Status field shows whether the correspondent is Active or Inactive. You cannot send a message using the SWIFT network to an inactive correspondent. This is a display-only field. For details on how to change the Correspondent Status, refer to "Activating and Deactivating Correspondents" on page 235. 5. Click Preferred Language to specify the preferred language that Alliance Access must use when expanding messages sent to the correspondent. 229 Alliance Access 7.0.20 6. In the Comments field, enter any general comments about the correspondent. 7. The Last Modified Date field shows the date on which the correspondent record was last modified. This is a display-only field. Complete the Integrated Application tab: 1. Click the Integrated Application tab. 2. The Defined Applications/Available column shows all the applications that your organisation is licensed to use. SWIFT is not listed, as it is always licensed. You use the Defined Applications column list panes to define which of your applications can be used to communicate with the correspondent. Click the transfer button to move the applications that you have chosen from the Defined Applications/Available column into the Selected column. To move an application out of the Selected column back to the Available column, select it and click the reverse transfer button. 3. The Preferred Networks/Available column shows all the defined applications for the correspondent that are also network applications. By default, Alliance Access sends any message to the correspondent using the first network application in this list that can handle the message format, unless you specify a different network application during message creation or modification. Your correspondent may prefer you to use the applications in a specific order. For example, a correspondent may prefer that messages are sent on the SWIFT network, and if this fails, that messages are sent on another network. You can specify the correspondent's preferred order of applications by moving applications from the Selected column to the Available column and then moving them back to the Selected column in a different order. Click the transfer button to move the applications that you have chosen from the Preferred Networks/Available column into the Selected column. 230 System Management Guide Updating the Correspondent Information File To move an application out of the Selected column back to the Available column, select it and click the reverse transfer button. Note 4. The OTHER network is available from the list of preferred networks if the Application Development Toolkit Runtime is licensed. If a correspondent has been assigned the OTHER network, then this is shown in the Message Preparation applications. The network choice is made in the Network tab in the Message Creation and Message Modification applications. Alliance Access displays additional tabs in the Correspondent Details window for each defined application that you selected. For information about how to complete: • the APPLI tab, see "Completing the APPLI Tab" on page 231 5. After entering details for each defined application,select Add from the Correspondent menu to add the new correspondent record to the CIF. 20.6.2 Completing the APPLI Tab To complete the APPLI tab: 15 July 2011 1. Click the APPLI tab. 2. Click Profile to specify whether the application interface profile is specific to this correspondent or is inherited from an existing correspondent. The available choices depend on the correspondent type. 231 Alliance Access 7.0.20 Select: • Specific if the profile is specific to the correspondent and is not inherited from a parent correspondent. • Same as Department if the correspondent is an Individual for whom the associated Department correspondent exists, and you want the correspondent to inherit its APPLI profile from that Department. • Same as Institution if the correspondent is a Department for whom the associated Institution correspondent exists, and you want the correspondent to inherit its APPLI profile from that Institution. 3. Click Exit Point and select the name of the Alliance exit point to which any messages for the correspondent are to be routed. This is useful primarily for messages received for internal correspondents. For an example of this, in the case of alarm messages, see "Displaying Alarm Distribution" on page 179. Another use is when you cannot send a message directly to an external correspondent. You can define an exit point for messages to that correspondent. Alliance Access routes any message to the correspondent to the exit point automatically. You can then transmit the message to the correspondent by some other communication method. For information about defining exit points, see "Managing Exit Point Profiles" on page 302. 20.6.3 Parent and Child Correspondents Overview When you create a correspondent, you can: • either enter every detail for the correspondent - you must always do this when you create an Institution correspondent • or specify that some details are inherited (copied) from an existing correspondent with which the new correspondent is associated. These details are called a profile. Only Department or Individual correspondents can inherit details. Using profiles makes it easier for you to create and maintain correspondents that have common features. For example, suppose you create an Institution correspondent. The Institution has a Department at the same address, and the Department is also a correspondent. When you create the Department correspondent, you click Profile in the Details area and specify that the correspondent profile is Same as Institution. This means that the Department correspondent inherits details such as the city, country, address, and so on from the Institution correspondent, and you do not need to enter them again. Another advantage is that if you make changes to any of these details for the Institution correspondent, the details for the Department correspondent change automatically. In the above example, the Institution correspondent acts as a parent to the Department correspondent. The Department correspondent is a child correspondent, because its correspondent profile is inherited from the Institution. A Department can itself be a parent to Individual correspondents, even if the Department is also a child to an Institution, as this more complex example shows: 232 System Management Guide Updating the Correspondent Information File Department A Department B Individual 1 Individual 2 PARENT to Departments A and B CHILD to Institution PARENT to Individuals A and B CHILD to Departmment B D0540051 Institution Within the Correspondent Details window, the Correspondent Profile and APPLI, tabs each have a Profile field. If you select Same as Institution or Same as Department in this field, then all the other fields become display-only. When details have been associated in this way, any changes made to the parent record are automatically applied to the child record. The fields in the Other tab cannot be inherited. Parent/child records are useful for sharing common details between records whilst maintaining important differences. The following procedure describes how to create such correspondents. To set up parent/child correspondents: This procedure sets up the parent/child correspondents as described in the previous example: 1. First create the Department A correspondent. Select the parent institution and choose the New As command from the Correspondent menu. 2. Select the Correspondent Profile tab. 3. Enter the BIC-11 address of the Institution parent record. 4. Select Department as the Correspondent Type. 5. Enter the Department name. 6. Select Same as Institution from the Profile field. This means that the Department A correspondent inherits the Institution's address and location details. The inherited fields change to display-only. 7. Complete the fields in the Other tab. 8. Select Add from the Correspondent menu. 9. You can now create the Department B correspondent. Select the parent institution and choose the New As command from the Correspondent menu. 10. Enter the BIC-11 address of the Institution parent record. 11. Select Department as the Correspondent Type. 12. Enter the Department name. 15 July 2011 233 Alliance Access 7.0.20 13. Select Same as Institution from the Profile field. This means that the Department B correspondent inherits the Institution's address and location details. The inherited fields change to display-only. 14. Complete the fields in the Other tab. 15. Select Add from the Correspondent menu. PARENT to Departments A and B Institution Department B Same correspondent profile as Institution Same correspondent profile as Institution D0540052 Department A If you now change the address of the Institution, then Departments A and B both inherit the changed address, and so you do not have to update their details. Note 20.7 A child correspondent can only inherit profiles from an existing correspondent, so always try to create a parent correspondent before you create any of its children. If, for some reason, you create the child correspondents first and then the parent, you must update the child correspondent records later so that they inherit their profiles from the parent. Modifying Correspondent Records Overview If necessary, you can modify the details for a specific correspondent in the CIF. To modify correspondent details: 1. 234 Double-click the correspondent within the Correspondent File window. The Correspondent Details window appears. System Management Guide Updating the Correspondent Information File 2. Change the correspondent details as required. For information about the fields, and options, see "Creating Correspondents". 3. Select Modify from the Correspondent menu to save the modified record to the CIF. You can move up and down the list of correspondents with the Correspondent Details window open. The details of each correspondent appear automatically in the Correspondent Details window as you do so. To move up or down the list of correspondents: • Select Previous or Next from the Correspondent menu, or click the equivalent buttons in the toolbar. 20.8 Activating and Deactivating Correspondents Overview You can use this feature to prevent messages being sent to selected correspondents. Messages can only be sent to a correspondent over the SWIFT network if their correspondent record is active in the CIF. A check to ensure that a correspondent record is active takes place as part of the routing rules. Messages sent using the Application Interface are not checked because the network and the correspondents are both internal. If the correspondent record is inactive then you cannot send messages to it. Messages addressed to an inactive correspondent are routed to correction queues according to the routing rules defined on the Alliance Access server. To activate or deactivate correspondents: 15 July 2011 1. If the correspondents' status is not shown, then select View/Status from the Correspondent menu to display it. 2. Click one or more of the correspondents listed. 235 Alliance Access 7.0.20 3. Select the correspondents that you want to activate or deactivate. 4. Select Activate or Deactivate from the Correspondent menu. Note 20.9 You cannot activate or deactivate a correspondent if that correspondent's details are being modified at the time. Removing Correspondent Records Overview You can remove correspondents records from the CIF. To remove correspondents: 1. Click one or more of the correspondents listed. 2. Select Remove from the Correspondent menu. You are prompted to confirm the correspondents' removal. If you remove a correspondent, then it cannot be recovered. Note You can only remove a parent correspondent if you first either remove all its child correspondents, or you modify the child correspondents so that they no longer inherit the parent's profiles. For details about parent and child correspondents, see "Parent and Child Correspondents" on page 232. 20.10 Managing Aliases Overview When you use the Message Creation application to create a message, you can specify that the message is sent to an alias instead of an actual BIC-11 address. An alias is an alternative name for a correspondent, or group of correspondents. If the alias is for a single correspondent then you can use it to send any message type. If the alias is for a group of correspondents then you can send only non-financial messages (MT 999s). The message is broadcast to the group of correspondents which means that a single message is created and sent to them all. Aliases are stored in the CIF, and you use CIFA to maintain them. 20.10.1 Searching for Aliases Overview You use the Correspondent File - Search Criteria dialog box to set the criteria for a search on aliases. Your search criteria can include alias details, correspondent details, or a combination of both. For example, you can find all the aliases for a correspondent by leaving the Alias field empty and entering only the correspondent details. To search for aliases: 236 1. If aliases are not displayed in the Correspondent File window, then select Alias from the View menu. 2. Select Search from the Alias menu. The Correspondent File - Search Criteria window appears. System Management Guide Updating the Correspondent Information File 3. In the Alias field, enter the alias name to search for. 4. Click Type. Select: • Any to search for correspondents of any correspondent type • Institution to search only for correspondents that are Institutions • Department to search only for correspondents that are Departments • Individual to search only for correspondents who are Individuals. 5. In the Institution field, enter the BIC-11 address of the Institution to search for. Use of wild cards is allowed. 6. If the Type field is set to Any, Department or Individual, then the Department field appears. In this field, enter the name of the department within the Institution that you are searching for. Use of wild cards is allowed. 7. If the Type field is set to Any or Individual, then the Last Name and First Name fields appear. In the Last Name field, enter the last name of the individual who you are searching for, and in the First Name field, enter the individual's first name. Use of wild cards is allowed. 8. Click Search . The aliases meeting all your specified criteria are displayed in the Correspondent File window. 20.10.2 Creating Aliases Overview You use the Alias Details window to create and maintain aliases (alternative names) for a correspondent, or group of correspondents. When you create an alias, you define: • the name of the alias • the individual correspondent or group of correspondents to whom the alias is assigned. A correspondent or group of correspondents can have more than one alias. To create an alias for one or more correspondents: 1. If aliases are not displayed in the Correspondent File window, then select Alias from the View menu. 2. Either select New from the Alias menu or if you want the new alias to be based on an existing one, highlight the existing alias and select New As from the Alias menu. The Alias Details - New window appears. 15 July 2011 237 Alliance Access 7.0.20 3. In the Alias Name field, enter the name of the alias that you want to give to a correspondent, or group of correspondents. 4. The Number of Correspondents field displays the number of correspondents to whom the alias is assigned. This is a read-only field. 5. To create an alias for one or more correspondents, you must first search for and list those correspondents in the Alias Details window. To search for correspondents, click Search Correspondents... in the Alias menu. The Correspondent File - Search Criteria dialog box appears. 6. Enter your search criteria for the correspondents in the Correspondent File - Search Criteria dialog box. For details of the fields, see "Specifying Search Criteria" on page 220. 7. Click Search in the Correspondent File - Search Criteria dialog box. The correspondents meeting all your specified criteria appear in the Correspondents/Available column in the Alias Details window. If a large number of correspondents are listed, then you can use the Starting with field to find correspondents quickly. Simply enter the first few characters of the Institution name in the Starting with field. The Correspondents/Available column displays a list of correspondent names, starting with the first correspondent name whose first few characters match those in the Starting with field. For example, if you enter ALB, the first correspondent with an Institution name starting with ALB appears at the top of the column. Click the transfer button to move the correspondents to whom the alias applies from the Correspondents/Available column into the Selected column. To move a correspondent out of the Selected column back to the Available column, select it and click the reverse transfer button. 8. Select Add from the Alias menu to add the new alias to the CIF. The alias is assigned to the correspondent, or group of correspondents shown in the Selected column. You can move up and down the list of aliases while the Alias Details window is open. The details of each alias appear automatically in the window as you do so. 238 System Management Guide Updating the Correspondent Information File To move up or down the list of aliases: • Select Previous or Next from the Alias menu, or click the equivalent buttons in the toolbar. 20.10.3 Modifying Aliases To modify an alias: 1. Double-click the alias in the Correspondent File window. The Alias Details window appears. 2. Change the details as required. The fields and buttons are described in "Creating Aliases" on page 237. 3. Select Modify from the Alias menu to save the modified record to the CIF. 20.10.4 Removing Aliases To remove an alias from the CIF: 1. Select the alias in the Correspondent File window. 2. Select Remove from the Alias menu. You are prompted to confirm the removal. If you remove an alias, then it cannot be recovered. 20.11 Managing Currency Records Overview You can use CIFA to create and maintain the currency records in the CIF. Most of the details in the CIF are imported from the Bank File. Each currency record in the CIF includes a field which defines whether the record must be updated automatically when a Bank File is loaded into Alliance Access. If you do not want to wait for the next update of the Bank File, then you can modify existing currency records and add new currency records manually. 20.11.1 Creating Currency Records To create a currency record in the CIF: 1. If currencies are not displayed in the Correspondent File window, then select Currency from the View menu. 2. Either select New from the Currency menu or if you want the new currency record to be based on an existing record, highlight the existing code and select New As from the Currency menu. The Currency Details - New window appears. Fill in the relevant fields. For a description of the fields displayed in this window, see "Currency Details Window" on page 240. 3. Select Add from the Currency menu to add the new currency record to the CIF. After the Currency Details window is open, you can move up and down the list of currency records. The details of each currency appear automatically in the window as you do so. 15 July 2011 239 Alliance Access 7.0.20 To move up or down the list of currency records : • Select Previous or Next from the Currency menu, or click the equivalent buttons in the toolbar. 20.11.2 Currency Details Window Description Currencies can be displayed by selecting Currency from the View menu in the Correspondent File window. Example of Currency Details - New window Field descriptions Currency Code A unique 3-character ISO standard currency code for the currency. Currency Name The full name of the currency. Number of Digits The maximum number of digits needed to correctly display fractional amounts of the currency. This can be any number between 0 and 6. Update on BIC Load Select: • No if you do not want this currency record to be updated when a Bank File is loaded. • Yes if you want the record to be updated when a Bank File is loaded. This means that the record may be changed or even deleted as a result of the update. By default, every new record has this button set to No. 20.11.3 Modifying Currency Records To modify a currency record: 240 1. Double-click the currency record in the Correspondent File window. The Currency Details window appears. 2. Change the details as required. The fields and buttons are described in "Currency Details Window" on page 240. 3. Select Modify from the Currency menu to save the modified record to the CIF. System Management Guide Updating the Correspondent Information File 20.11.4 Removing Currency Records To remove a currency record from the CIF: 1. Select the currency in the Correspondent File window. 2. Select Remove from the Currency menu. You are prompted to confirm the removal. If you remove a currency record, then it cannot be recovered. 20.12 Managing Country Records Overview You can use CIFA to create and maintain the country records in the CIF. Most of the details in the CIF are imported from the Bank File. Each country record in the CIF includes a field that defines whether the record must be updated automatically when a Bank File is loaded into Alliance Access. If you do not want to wait for the next update of the Bank File, then you can modify existing country records and add new country records manually. 20.12.1 Creating Country Records To create a country record in the CIF: 1. If countries are not displayed in the Correspondent File window, then select Country from the View menu. 2. Either select New from the Country menu in the Correspondent File window or, if you want the new country record to be based on an existing record, highlight the existing code and select New As from the Country menu. The Country Details - New window appears. Fill in the relevant fields. For a description of the fields displayed in this window, see "Country Details Window" on page 241. 3. Select Add from the Country menu to add the new country record to the CIF. After the Country Details window is open, you can move up and down the list of country records. The details of each country appear automatically in the window as you do so. To move up or down the list of country records: • Select Previous or Next from the Country menu, or click the equivalent buttons in the toolbar. 20.12.2 Country Details Window Description Countries are displayed by selecting Country from the View menu in the Correspondent File window. 15 July 2011 241 Alliance Access 7.0.20 Example of Country Details - New window Field descriptions Country Code A unique 2-character ISO standard country code for the country. Country Name The full name of the country. Update on BIC Load Select: • No if you do not want this country record to be updated when a Bank File is loaded. • Yes if you want the record to be updated when a Bank File is loaded. This means that the record may be changed or even deleted as a result of the update. By default, every new record has this button set to No. 20.12.3 Modifying Country Records To modify a country record: 1. Double-click the country record in the Correspondent File window. The Country Details window appears. 2. Change the details as required. The fields and buttons are described in "Country Details Window" on page 241. 3. Select Modify from the Country menu to save the modified record to the CIF. 20.12.4 Removing Country Records To remove a country record from the CIF: 242 1. Select the country in the Correspondent File window. 2. Select Remove from the Country menu. You are prompted to confirm the removal. If you remove a country record, then it cannot be recovered. System Management Guide Managing Message Partner Profiles 21 Managing Message Partner Profiles Overview This section explains how to configure the Application Interface to manage the transfer of messages and files between Alliance Access and a back-office application, printer, or other application. 21.1 Application Interface Description The Application Interface controls the transfer of messages and files between Alliance Access and back-office applications, printers, or any other system that communicates with Alliance Access. Suitable messages for transferring include SWIFT FIN, MX, FileAct, and system messages. Suitable files include payload files, or files that contain several messages (such as for Bulk Payments). Within the Application Interface, a message partner represents the external application or product that communicates with Alliance Access. A message partner profile specifies how each message partner communicates with Alliance Access, and allows you to control and monitor the communication sessions. Alliance Access transfers a message to a message partner through an exit point, which holds the message in a queue before transferring it to the message partner. Each exit point is associated with a particular message partner. The Application Interface allows you to: • create, modify, or remove exit points and message partner profiles • assign an exit point to a message partner • control and monitor communication sessions between Alliance Access and a message partner. 21.2 Message Partners and Message Partner Profiles Message partner A message partner is an external application, such as, a back-office application, a printer, or a mainframe connection. The Application Interface manages the transfer of files and messages between Alliance Access and a message partner using the profile that is defined for that message partner. Profile of a message partner A message partner profile specifies the parameters necessary to transfer message and files between Alliance Access and a message partner. The most important of these parameters is the connection method, which defines the type of connection protocol and the data format to be used for the transfer. Every application that communicates with Alliance Access must have a message partner profile defined in the Application Interface. You can view message partner profiles in the Message Partner view of the Application Interface main window. 15 July 2011 243 Alliance Access 7.0.20 Note When operating Alliance Access in low-speed mode, the message partner details are refreshed after you click in the message partner list. Managing communication sessions Once a message partner profile is configured, an operator with the appropriate permissions can view details about the current ongoing communication session or about the last communication session. 21.3 Message Flow in the Application Interface Message Processing Function Message processing functions (MPFs) control the exchange of messages between the Application Interface (AI) and the message partners. The Application Interface Services (MXS) component manages the details of all message partner profiles and exit points. Messages are handled differently depending on the direction of the message flow: • "Input message flow" on page 244 • "Output message flow" on page 245 Input message flow INPUT SESSION Alliance AI_from_APPLI Application Interface MESSAGE PARTNER MESSAGE PARTNER D0540053 MESSAGE PARTNER Incoming messages from a message partner are placed in a common AI_from_APPLI queue until they are processed by a message processing function. This queue is referred to as the "Application Interface (AI) inbound" queue. This queue is used to route all incoming messages from all message partners using the connection methods, Direct FileAct, File Transfer, Interactive, WebSphere MQ, or SOAP. 244 System Management Guide Managing Message Partner Profiles Output message flow exit point 1 MESSAGE PARTNER D0540054 Alliance Application Interface OUTPUT SESSION Outgoing messages to a message partner are placed in the exit point queue that is assigned to that message partner. The messages remain in the exit point until they are processed by a message processing function.When more than one exit point is assigned to a message partner during an output session, then a polling mechanism services each exit point queue in turn. An operator can create or remove exit points, or assign an exit point to a message partner. Output session with multiple exit points OUTPUT SESSION Polling cycle exit point 2 Alliance MESSAGE PARTNER D0540055 exit point 3 Application Interface exit point 1 21.4 Connection Methods Connection method description A connection method is part of a message partner profile. It specifies the type of communication protocol and the data format that is used to transfer messages between Alliance Access and a back-office application or external product. The location of the message or parameter files for transmission are specified as a connection point, which is associated with a connection method. The Application Interface application supports several connection methods. This section provides basic descriptions of these connection methods after the summary table. 15 July 2011 245 Alliance Access 7.0.20 Note All sessions that use the Interactive, WebSphere MQ, and SOAP connection methods are run on the server. Bidirectional message exchange Bidirectional message exchange during the same session (to and from Alliance Access a message partner) is possible with the following connection methods: • Interactive • File Transfer • SOAP FileAct message exchange To exchange FileAct messages between Alliance Access and a message partner, the following connection methods are available: • Direct FileAct • File Transfer • SOAP • WebSphere MQ Summary of connection methods and data formats The following table lists the available connection methods: Connection Method Data Format Connection Point Protocol Direct FileAct NA Directory NA File Transfer DOS PCC (ST200 PCC) Directory Batch RJE (ST200 RJE) Directory Batch CAS 1/2 (NDF/NIF) Directory CAS Batch MERVA/2 Directory Batch XML Version: Directory Batch • 1 • 2 Revision Original, 1, 2, or 3 Interactive NDF/NIF TCP/IP sockets CAS Interactive Print Expanded File ASCII Write Printer Spooled NA SOAP SOAP 246 XML version 2 Revision 2 or 3 System Management Guide Managing Message Partner Profiles Connection Method Data Format Connection Point Protocol WebSphere MQ MQ-MT NA MQ Messages XML version 2 Revision Original, 1, 2, or 3 Direct FileAct The Direct FileAct connection method enables the transfer of a payload file between Alliance Access and a back-office application. A payload file contains the data that is to be transferred. The FileAct transmission parameters are deduced from the message partner profile. You do not need to send an XML version 2 message or a file that contains the FileAct transmission parameters when you send each payload file. Dedicated Direct FileAct input and output file directories are accessible to both Alliance Access and the back-office application or operator. The back-office application or an operator put the payload files in these directories to send the files over SWIFTNet, or they get the payload files received from SWIFTNet from these directories. Direct FileAct also enables back-office applications to benefit from simplified reporting of network acknowledgements and of reconciled delivery notifications. A message partner profile with the Direct FileAct connection method must exist for each correspondent that will use Direct FileAct to transmit files between each other. The Direct FileAct connection method requires the licence package 22: DIRECT FILEACT. The file-transfer session can be started automatically or manually. For example, if a back-office application stores a payload file in a pre-configured input directory, then the presence of the file in the directory can automatically start a file-transfer session. You can define a message partner profile for Direct FileAct only through the Alliance Configuration package on Alliance Web Platform. You can also view a message partner profile for Direct FileAct through the Alliance Monitoring package on Alliance Web Platform. File Transfer The File Transfer method enables the transfer of batch files containing multiple FIN, FileAct, or InterAct messages between Alliance Access and a back-office application. For FileAct messages, in addition to transferring a payload file, Alliance Access or a back-office application also transfers an XML version 2 message containing the FileAct settings which control the file transfer, and an optional parameter file. The file-transfer session can be started automatically or manually. Note For FileAct messages, the body of the XML version 2 message does not contain the payload of the message to be transmitted. Instead, the body of the message points to the location of the payload file. To exchange FileAct messages, XML version 2 with revision 2 or 3 is required. For each message format, the communication media are file system directories. Alliance Access can read or write a batch message file from or to a directory in a local or remote file system. The File Transfer connection method supports the following message file data formats: Data format Common Application Server (CAS) 15 July 2011 Purpose CAS standards 1 and 2 which support the sub-formats ASN.1 or text encoding (only CAS version 2) used for Network Dependent Format (NDF) or Network Independent Format (NIF) 247 Alliance Access 7.0.20 Data format Purpose DOS-PCC used for batch input and output of messages, which enables you to read or write an ST200 DOS message file MERVA/2 used for batch transfer (to and from Mainframes) in IBM MERVA/2 format Remote Job Entry (RJE) used for batch input and output of messages in ST200 RJE format XML used for batch input and output of MX or FileAct messages, or for FpML documents You can find examples of the data formats that you can use with the File Transfer method in the following directory, which is beneath your installation directory: Windows: <Alliance installation directory>\mxs\batch_examples UNIX: $ALLIANCE/MXS/batch_examples Interactive The Interactive method supports bidirectional message transfer with back-office applications according to the Common Application Server (CAS) standards 1 and 2 that support sub-formats ASN.1 or text encoding (only CAS version 2) for Network Dependent Format (NDF) or Network Independent Format (NIF). Print The Print method enables you to specify how to print messages in batch from Alliance Access to either a printer or a file in a user-specified directory. The file or printer is specified as a connection point in a message partner profile. For Alliance Workstation, it is possible to specify the host name of the machine where the printer is connected, that is, on the local machine or on the server machine. Output messages can also be printed in ST200-like format, which can also include warning indications, or eye-catchers, in the header of the output. SOAP The SOAP connection method enables the exchange of MT, XML-based messages, and FileAct messages between Alliance Access and back-office applications. The SOAP connection method requires the licence package 14:SOAP ADAPTER and supports only the XMLv2 data format. The parameters that control the file transfer include a pointer to the payload file, service, receiver of the file, header information, and notification options. These file-transmission parameters are carried in an XMLv2 message. The SOAP Host Adapter supports the exchange of FileAct messages over HTTPS in two modes: • Full FileAct mode, where file transmission parameters and the FileAct payload are transferred in XMLv2 format and the data exchange uses Web services over HTTPS. • Mixed FileAct mode, where the file transmission parameters are carried in an XML version 2 message that is transferred using Web services over HTTPS, whereas the FileAct payload is transferred over the local file system 248 System Management Guide Managing Message Partner Profiles WebSphere MQ The WebSphere MQ connection method enables FIN, XML-based, or FileAct messages to be exchanged between Alliance Access and back-office applications through IBM WebSphere MQ. This connection method requires the licence package 13:MQ HOST ADAPTER. The WebSphere MQ method supports the following data formats: • MQ-MT • XML version 2, with revision Original, 1, 2, or 3. The exchange of FileAct messages over WebSphere MQ requires XML version 2, revision 2 or 3. The WebSphere Host Adapter supports the exchange of FileAct messages over WebSphere MQ in two modes: • Full FileAct mode - where both the XML version 2 message and the FileAct payload are transferred over WebSphere MQ. • Mixed FileAct mode - where the XML version 2 message is transferred over WebSphere MQ, whereas the FileAct payload is transferred over the local file system. 21.5 Message Partner View Description After you start the Application Interface, the Message Partner window appears (if the message partner view is selected). This window lists all the defined message partners, including the message partners that are created through the Alliance Access Configuration package on Alliance Web Platform. Tip 15 July 2011 To view the details of a message partner that uses the Direct FileAct connection method, you must use the Alliance Access Configuration package on the Alliance Web Platform. 249 Alliance Access 7.0.20 Example of Message Partner window Field descriptions Partner Name The name of the message partner profile. Partner Id An internal system ID of the message partner profile. This ID is used together with the session number to form the name of both the parameter file and the message file for automatic fileoutput sessions. Status A message partner profile can have one of the following statuses: • Enabled - the profile is approved for use • Disabled - the profile is not authorised and cannot be used in a session • Disabling - at the end of its current session, the profile has the status Disabled. Note An Interactive Message Partner that is in the state "disabling" only becomes disabled after the current session is stopped. Session Status Indicates whether the message partner has a session active, and the status of that communication session. For more information about the statuses, see "Status of Message Partner Sessions" on page 251. Session Indicates the number of the latest session in which a message partner was participating or is still participating in. Description A description of the message partner profile. 250 System Management Guide Managing Message Partner Profiles 21.6 Status of Message Partner Sessions Description You can monitor message partners that have a certain communication status, such as when they are aborting or recovering. You can monitor any or all of the following session statuses: Status Description Aborting The session is closing down as a result of an Abort command being issued or a serious failure, such as an authentication error. Interactive sessions may also be aborted by the message partner. You can use the Event Journal to examine the details of all abort events. Such events are classified as System, and are described with an abort reason and an abort text. For sessions involving the CAS protocol, the description of an event may include the expected session or sequence number. Closed No transfer of messages is currently taking place with the message partner. Closing The session is closing down for one of the following reasons: • An end-of-file (EOF) was reached during a batch input session • All the messages queued at the exit points when the Run Session command was issued have been transferred in this batch output session • A Stop Session command was issued. Note that interactive sessions may also be stopped by the message partner. Interrupted The message partner has lost the connection to WebSphere MQ. Only applicable to WebSphere MQ message partners. Open The session is active and messages are being transferred. Opening The session is started but is not yet open. The Run Session or Start Session command was issued and the session is initialising. Such a session is said to have been started manually in the Application Interface. Some sessions may be started directly by the message partner. This is optional for an interactive session. Recovering 21.7 The session is recovering from a session failure, such as an abort request or a system restart. Preparing the Application Interface for a Transfer Session Purpose Before working with the Application Interface for the first time, you must define a number of key objects. Warning During day-to-day operations, do not open the message partner profiles or exit point profiles unless you need to modify them or add new profiles. Automatic message partner sessions All sessions using automatic message partners are run on the server. 15 July 2011 251 Alliance Access 7.0.20 All message files or parameter files that are referenced in an automatic message partner profile must be local to the server. The operator profile of the operator who loads or moves files to the server must have the Files on Server permissions assigned for the Access Control application. By default, these permissions are assigned to the Superkey and Supervisor operator profiles. Preparing the Application Interface 21.8 1. Ensure that you have correctly configured and enabled message partner profiles, to control the flow of messages and files. 2. Ensure that the routing is defined and active. For example, to route messages and files to an exit point associated with a message partner profile, you must have routing rules defined to do this. 3. To change the existing default exit point profiles, you can create an exit point which stores files or message before they are transferred to a message partner. 4. Run the Application Interface and start a message partner session to transfer files or messages between Alliance Access and the message partner. Creating a Message Partner Profile Overview The purpose of the message partner profile is to specify the connection method and the communication parameters for communication between the Application Interface and a message partner. You can create a message partner profile from scratch, or create one using an existing or default profile as a template. You can find a list of default profiles in "Default Message Partner Profiles" on page 393. Tip To create a message partner that uses the Direct FileAct connection method, you must use the Configuration package on the Alliance Web Platform. PKI signatures and MAC/PAC trailers You can specify whether you want to transfer PKI signatures when sending FIN messages to this message partner, and, if applicable, to transfer MAC/PAC trailers also. For more information, see "File Transfer Connection Details Window" on page 258. Back-office applications must be ready to receive and store PKI signatures. To define a profile: 1. Start the Application Interface application. 2. Select the Message Partner view, if it is not already selected. 3. Do you want to create a profile using an existing profile? If yes, then select a suitable profile from the Message Partner window. Select New As from the Message Partner menu. If no, then select Deselect All from the Edit menu, to clear any previous selections from the window. Then, select New from the Message Partner menu. The Message Partner New window appears. 252 System Management Guide Managing Message Partner Profiles 4. In the Profile tab, type the name of the profile in the Message Partner field. Enter up to 14 alphanumeric characters for the profile name. 5. Type a description of the profile in the Description field. Enter up to 50 alphanumeric characters for the description. 6. Specify the connection method and the direction of the message flow for the connection method. Then define the parameters of that method. For more instructions, see "Specifying the Connection Method" on page 253. 7. Set local authentication in the Authentication tab, if required. For more instructions, see "Specifying Local Authentication" on page 291. 8. Depending on the direction of the message flow (Allowed direction), complete the emission or reception parameters in the following tab or tabs: • To Message Partner - Emission tab. See "Specifying the Emission Parameters" on page 281. • From Message Partner - Reception tab. See "Specifying the Reception Parameters" on page 285. • To & From Message Partner - Emission tab and the Reception tab. See "Specifying the Emission Parameters" on page 281 and "Specifying the Reception Parameters" on page 285. 9. Select Add from the Message Partner menu, to save the message partner profile. The profile is saved with the status "Disabled". To discard a profile, select Close. After selecting Close, confirm that you want to exit without saving the new entries. 10. Enable the profile before Alliance Access can use it in a communication session. See "Enabling a Message Partner Profile" on page 296. Advantages of specifying Allowed direction Setting the direction of the message flow in the Message Partner Profile has the following advantages: • You do not have to specify the session direction at session run time. • The risk of transmitting a message in the wrong direction at session run time is reduced. Transmission of a message in the wrong direction can result in mistakes, such as the overwriting of an existing message file. 21.9 Specifying the Connection Method Overview After you select a connection method, a number of parameter fields become available for that method. This section provides instructions for defining each of the connection methods, including the required parameters and the type of input that Alliance Access expects. Sometimes, a selection in one field has a subsequent effect on other fields. To view the details of a message partner that uses the Direct FileAct connection method, you must use the Configuration package on the Alliance Web Platform. 15 July 2011 253 Alliance Access 7.0.20 Note A file name cannot have more than 255 characters in length (including path names to the files), and must not contain blanks. 21.9.1 Print Connection Method Purpose The connection point used for a Print session is the name of a printer, or the full pathname of a directory where the message print file can be stored. For auto sessions, this pathname must never point to the "root" directory '/'. When Workstation is connected to remote servers, it may be possible to send messages to printers on either system, that is, a printer connected to the Server machine or alternatively a printer connected to the Workstation machine. To select the correct machine, the Printer hostname field must contain the name of the required machine. The following printers are available: • When connecting to UNIX servers, the print devices defined in SMA are proposed. • When connecting to Windows servers, all printers available to the server machine are proposed. • If the Workstation machine is selected, then all printers available to the Workstation machine are proposed. For a detailed description of the concepts of the Print connection method, see Appendix F, "Connection Methods in AI" on page 553. To select Print as a connection method: 254 1. Select To Message Partner from the Allowed direction drop-down menu. 2. In the Profile tab, select the Print connection method. Additional fields appear in the Profile tab. System Management Guide Managing Message Partner Profiles For a description of the fields displayed in this window, see "Print Connection Details Window" on page 256. 3. Choose the type of print session you require: • Automated - go to Step 4 on page 255 • Manual - go to Step 5 on page 256 4. In the Session initiation field, select Automatic. Automatic printing cannot be done on the Alliance Workstation machine. Define how you want the print session to start, by specifying either: The number of messages that are queued at the assigned exit point(s) In the Number of messages = field, type the number of messages that must be queued to trigger a session. One or more specific times of the day In the Or at (hh.mm) field, enter the time(s) at which the automated sessions must start. After you specify a start time, click the transfer button to add the time to the list box. You can add several times. The activation list displays the times at which automated sessions are scheduled to start. To start a session automatically, you can combine the criteria of "number of messages queued" together with a specified time. For example, you can specify that the session must start after ten messages are queued, or at 10:00, 11:00, and 12:00. This setting would result in the following: • if ten messages are queued before 10:00, then a session starts • at 10:00, a session starts 15 July 2011 255 Alliance Access 7.0.20 • a session starts between 10:00 and 11:00 each time that ten or more messages are queued • a session starts at 11:00, and so on 5. In the Session initiation field, select Manual. Do the following: 1. Start the session using either the Start Session or Run Session commands. A print job is not submitted until after the batch session is complete. 2. If you started the session using the Start Session command, then you have to stop it using the Stop command before a print job is submitted to the printer. 3. In the On field, specify whether the session is to run on the server or workstation. 21.9.1.1 Print Connection Details Window Description To select Print as a connection method, click Connection Method in the Profile tab and select Print. Example of Print Connection details 256 System Management Guide Managing Message Partner Profiles Field descriptions Session Initiation Select: • Manual, if you want operators to start sessions. • Automatic, if you want sessions to run automatically. The Alliance Access servers must be running and the message partner enabled. Note that, when connecting with Workstation, automatic print sessions can only be run on the printer connected to the server machine. Print to Use this button to direct printer output to either a known printer, or alternatively to an ASCII file. Filename pattern Type the full path of the directory where the print file is to be located. Local transfer command Type the name of the user-defined executable which handles the message files once they reach the back-office application. Printer hostname This field must contain the name of the server or local machine which has the printer connected to it. Printer name Select a printer by typing a system printer name. For more information about printer names, consult your system administrator. Page setup Use this field to set up the page paper size, orientation, and margins. Printer font Use this field to set up the print font style. Number of messages = Type the number of messages in the message partner's output queue. When the value specified here is reached, printing starts automatically. This field appears only for automatic printing. Or at (hh.mm) Enter the time(s) (using the format 2200 or 22.00) for automatic print sessions to start. You can specify multiple times during a 24-hour period. The times that you enter are automatically adjusted to the nearest 5-minute interval. This field appears only for automatic printing. 21.9.2 File Transfer Connection Method Overview The File Transfer connection method is described in detail in "File Transfer" on page 564. 15 July 2011 257 Alliance Access 7.0.20 21.9.2.1 Selecting File Transfer as the Connection Method To select File Transfer as a connection method: 1. Select one of the following directions from the Allowed direction drop-down menu: • To Message Partner • From Message Partner • To & From Message Partner - For the File Transfer method, this means 'To or From Message Partner'. 2. Click the Connection method button in the Profile tab and select File Transfer. Additional fields appear in the Profile tab. For a description of the fields displayed in this window, see "File Transfer Connection Details Window" on page 258. 21.9.2.2 File Transfer Connection Details Window Description To select File Transfer as a connection method, click the Connection method button in the Profile tab and select File Transfer. Example 258 System Management Guide Managing Message Partner Profiles Field descriptions Transfer PKI Signatures Select this option when you want Alliance Access to transfer PKI signatures when it exchanges FIN messages with a message partner. The PKI signature is always transferred for messages in XML version 2 format. If a back-office application is ready to receive and store PKI signatures, then you must select the Transfer PKI Signatures option. This option becomes available when: • the Allowed direction is set to To Message Partner or To & From Message Partner, and • the data format is RJE, CAS 2, DOS-PCC, or MERVA/2 Always transfer MAC/PAC Select this option if you want Alliance Access to add a dummy value (00000000) to the message if it does not contain MAC/PAC trailer. This option supports the back-office applications that require the use of MAC/PAC trailers. This option becomes available when: • the Allowed direction is set to To Message Partner or To & From Message Partner, and • the data format is RJE, CAS 2, DOS-PCC, MERVA/2, or XML version 2 Increment Sequence Number across Sessions Check this to have continuous sequence numbers. Session Initiation Select: • Manual, to allow operators to start sessions manually. In the On field, you can specify whether the session must run on the server or the workstation. • Automatic, to run sessions automatically. The Alliance Access servers must be running and the message partner enabled. When an Automatic session is started, any old files that remain in the directory are transferred to the message partner. You must run Automatic sessions on the server, not on the Alliance Workstation. Warning If you change Session Initiation from Manual to Automatic, then empty the input directory to ensure that messages are not sent twice. This applies to input sessions, where Allowed direction is set to From Message Partner or To & From Message Partner. Parameter File Select Required or Not Required. A parameter file contains the location of message files and other information including CRC results. If you want to create and use parameter files, then see Appendix G, "Parameter Files in AI" on page 633. 15 July 2011 259 Alliance Access 7.0.20 Format Recognition Select whether the format of input files is recognised automatically: • Auto-recognition recognises input files if they are in DOS, RJE, MERVA/2, CAS 2 (Common Application Server format version 2), ASN.1 encoded, or XML (version 1 and 2) format. The sub-formats NIF and NDF for CAS are recognised automatically. • Forced only recognises the format selected in the Data Format field. Files in any other formats are rejected during input. To recognise CAS 1 or CAS 2 text encoded, you must select Forced and specify the relevant parameters. Data Format Select from: • RJE (Remote Job Entry) files contain messages separated by dollar signs. They have no additional formatting. • DOS-PCC is the PC Connect file format. DOS-PCC files contain messages that begin with an ASCII Start of Header code and end with an End of Text code. • MERVA/2 is the IBM MERVA/2 format. • CAS is the format associated with the CAS (Common Application Server) protocol. • XML is the format used to support FpML documents, and batch input and output of MX and FileAct messages. Appendix D, "Message Formats Used in AI" on page 411 illustrates each of these formats. Sub-format If you selected CAS as the data format, then select either: • Network Dependent to output files in a format recognised by the SWIFT network. • Network Independent to output files in a format recognised by non-SWIFT networks, such as CHIPS. CAS version If you selected CAS as the data format, then select 1 or 2. CAS encoding If you selected CAS as the data format, then select ASN.1 or Text. Version If you selected XML as the data format, then select one of the following versions: • 1 • 2, to exchange files containing MT messages, XML-based messages, File messages, or a mixture of these in the same file. Revision Indicates the revision of the schema version, and can be: • Original • 1 260 System Management Guide Managing Message Partner Profiles • 2 (minimum revision required to exchange FileAct messages) • 3 (supports the SWIFTNet 7.0 distribution and dynamic copy features for messages and files) Note The revision specified is only used for output formatting ('To Message Partner' direction, and generating reports on the 'From Message Partner' direction). For the 'From Message Partner' direction, the revision is automatically detected regardless of the value specified. Input path name Type the input path, and then add a file pattern specifier to it: • * indicates that all files in the input directory must be input. For manual sessions, you can browse the input directory. • *.inp transfers all files with the extension .inp. This is the standard file extension for input files. You can also use any other file extension. For manual sessions, you can browse the input directory. • *.par if you are using parameter files. For manual sessions, you can browse the input directory. During file transfers, the directory is scanned and all files that match the specified file type are transferred. Do not use the same input directory for more than one automatic message partner. Output path name Type the output path, and then add a file pattern specifier to it: • * for manual sessions, the exact file name can be specified at session run time. • *.out gives all output files the extension ".out." This is the standard file extension for output files. You can also use any other file extension. • *.par, if you are using parameter files. Local transfer command Type the name of the user-defined executable which handles the message files once they reach the back-office application. This command has a specific syntax. For Windows servers, including an Alliance Workstation connected to a Windows server, type the following: cmd /Q /C start /B /WAIT /MIN <Drive letter>:\batch\lta.bat Where <Drive letter> is a mapped server drive. Parameters Type parameters for the user-defined executable. Output File Extension Type the file name of the extension to be used for output files (only for automatic sessions). Generate report file You can request a report about the processing of an input file by selecting the Generate report file option. 15 July 2011 261 Alliance Access 7.0.20 This option is available when: • the Allowed direction is From Message Partner or To & From Message Partner, and • the Data Format is XML Version 2 (see "XML Format 2") • the Format recognition to Forced The report is generated for sessions running on the server. If a session is run on Alliance Workstation, then it will run as if no report was requested, even if the message partner definition indicates to generate a report. The following options exist: Option Purpose No a report is not required Failure to generate a report only if an error occurs during the processing of an input file Failure or success to generate a report if the input file is processed successfully or if the processing fails If LAU is applicable, then it is also applied to the DataPDUs within the report file when generating the report (using the configured LAU keys). The receive key in the message partner definition is used to sign ReportPDUs for a message partner defined with unidirectional keys. Note If a message partner is defined with direction To & From Message Partner and a bidirectional key, then the send/receive key is used. The report is generated in the location specified in the Log Directory configuration parameter. For more information, see "Batch Input " on page 161. Input attachment directory For "From" message partners, this specifies the directory from which the payload files are read (used for the exchange of FileAct messages). Output attachment directory For "To" message partners, this specifies the directory where the payload files are written to. Optionally, you can also specify the file extension using field Extension (used for the exchange of FileAct messages). Extension For "To" message partners, you can (optionally) specify the file extension. Alliance Access will write the file with this extension to ease back-office integration. The remainder of the filename of the payload file (for "To" direction) is generated by Alliance Access. Run output session The Run output session panel becomes available if you select Automatic as the Session initiation field and if the Allowed direction is To Message Partner. Use the Run Output Session panel to define how you want the session to start, by specifying either: Parameter Number of messages = 262 Value The number of messages that are Description In the Number of messages = field, type the number of messages that must be queued to trigger a session. System Management Guide Managing Message Partner Profiles Parameter Value Description queued at the assigned exit point(s) Or at (hh.mm) One or more specific times of the day In the Or at (hh.mm) field, enter the times (using the format 2200 or 22.00) at which a print session must start automatically. You can specify multiple times during a 24-hour period. The times that you enter are automatically adjusted to the nearest 5-minute interval. 21.9.2.3 File Transfer Options Overview Before starting to define your profile, consider the following options. Automated or Manual File Transfer? With File Transfer, you can configure your message transfer session to start either manually or automatically. In the Profile tab is a field called Session initiation. A menu button permits you to select between automatic or manual initiation of a session. Manual initiation means that you have to start each session using the Start Session or Run Session command. Automatic sessions can be triggered by a time setting, or after a user-defined number of messages have accumulated at a particular exit point. Note Automatic sessions cannot be run on the Workstation machine. For manual sessions on a Workstation, you can specify whether the file is local or located on a server. Parameter File or Message File? The File Transfer connection method permits the use of parameter files which may be used together with message files in a message exchange session. A parameter file provides a way of indirectly addressing a message file, that is, it provides a pointer to a directory containing a message file. One benefit of this feature is to allow message files to be stored in separate input or output directories. Parameter files also serve in data integrity checking by holding the CRC result calculated on the message file. On reception of the message file, the CRC is recalculated and compared with the version stored in the parameter file. Parameter files may be used in both input and output sessions. If you want to create and use parameter files, then see Appendix G, "Parameter Files in AI" on page 633. Set Automatic Recognition of Input File Format, or Specify a Single Format? For input sessions, the File Transfer connection method permits you to "force" AI to accept input messages only when they are of a specified AI file format (and licensed - unlicensed formats are not recognised). Alternatively, the same button offers you the "auto-recognition" facility for input messages. With auto-recognition, all recognised AI file formats are accepted, that is, you do not have to specify the expected file format before starting the session. Note 15 July 2011 Messages transferred using the CAS 2 protocol are accepted only when Input File Format Recognition is set to Forced. 263 Alliance Access 7.0.20 21.9.2.4 Defining the Connection Point for File Transfer Introduction The File Transfer connection method is the only method in which you must specify a connection point for your message files. Note An overview of the various options for the file transfer connection method is shown in "Summary of Profile Settings" on page 570. The connection point for a File Transfer session is a pathname to either a parameter file or a message file. For input sessions, the directory containing this file is specified in the Input path name field. For output sessions, the directory containing this file is specified in the Output path name field. The format used in each of these fields is the same and can be expressed as follows: <connection point>\<matching pattern> Example for message files: C:\input\*.msg Example for parameter files: • on Windows: C:\input\*.par • on UNIX: /tmp/input/*.par The first step in defining the connection point for File Transfer depends upon the type of session that you require, that is, automated input or output, or manual input or output. For automated file transfer input or output session to take place, the software package 16:FILE AUTOMATED must be licensed on the system For automated output sessions, the Output path name field specifies where the message file and parameter file (if required) are placed after they are automatically generated. Note Sessions using automatic message partners only run on the server machine. For more information about automated output sessions, see "Defining the Connection Point for Automated Output Sessions" on page 265. For manual output sessions, the Output path name field specifies where the existing parameter file is situated (if required) and where the message file is placed after generation. In addition to this, the <matching pattern> part of the string can be used to specify a template for the filename or the parameter file. The user provides the full filename at session run time by means of the Start/Run Session dialog box. For details about manual output sessions, see "Defining the Connection Point for Manual Output Sessions" on page 267. For automated input sessions started by the input polling mechanism, the <connection point> part of the Input path name field specifies the directory where existing message or parameter files (if required) can be found. For details about automated input sessions, see "Defining the Connection Point for Automated Input Sessions" on page 269. For manual input sessions started with the Run/Start Session command, the actual parameter file or message file name is specified in the Connection Point field in the Start/Run Session 264 System Management Guide Managing Message Partner Profiles window. When used with parameter files, the location of the message file is found when the software examines field tag 050314 of the parameter file. Note For manual sessions when connected through a Workstation, the Connection Point field contains the default UNIX path. To browse to a different location, first clear this field. For details about manual input sessions, see "Defining the Connection Point for Manual Input Sessions" on page 270. "Summary of Profile Settings" on page 570 shows these options in a table. 21.9.2.4.1 Defining the Connection Point for Automated Output Sessions Note Automatic sessions cannot be run on the Workstation machine. To define the connection point for automated output sessions: 1. Click the Session initiation button in the Profile tab and select Automatic. 2. In the Output path name field, type the name of the directory where the parameter file or message file are to be placed when the session is completed. Example: • on Windows: C:\tmp\output\* • on UNIX: /tmp/output/* This must be an existing file path. A field validation process checks this string when the profile is modified. The <matching pattern> part of the Output path name field is ignored in this case, but has to be set to *. 3. Click the Data format button and select the message format that you require. Select from: • CAS • DOS-PCC • RJE • MERVA/2 • XML If you select CAS, then proceed to step 4. If you select XML, then proceed to step 6. For more information about the available formats, see Appendix D, "Message Formats Used in AI" on page 411. 4. When you select CAS, two additional menus appear, called Subformat and CAS version. Appendix D, "Message Formats Used in AI" on page 411 illustrates each of the available formats. Select a Subformat. 15 July 2011 265 Alliance Access 7.0.20 The following options exist: • Network Dependent, to specify that messages are to be transmitted in a format used by SWIFT • Network Independent, to specify that messages are to be transmitted in a network independent format. 5. For CAS version, you must decide between CAS 1 and CAS 2. For an introduction to the CAS protocol in AI, see "CAS Protocol" on page 574. 6. When you select XML, additional menus appear. In the Version menu, the following option exist: • 1 • 2, to exchange files containing MT messages, XML-based messages, File messages, or a mixture of these in the same file. In the Revision menu, the following options exist: • Original, the base version of the schema • 1, the revised version of the schema • 2 (minimum revision required to exchange FileAct messages) • 3 (supports the SWIFTNet 7.0 distribution and dynamic copy features for messages and files) 7. If your message files require a particular file extension, then specify this in Output file extension. If you do not provide an extension, then AI automatically appends the extension .out. 8. Select the way that you want your sessions to start. Automatic File Transfer offers you the choice of starting a session based on: • the number of messages queued at the assigned exit point(s) or • at one or more specific times of the day. To start a session based on the number of messages: In the Number of messages = field, type the number of messages that must be present at the assigned exit point(s) to trigger a session. To start a session at one or more times of the day: 1. In the Or at (hh.mm) field, enter the time(s) for your automated sessions to start. 2. When you have finished specifying a start time, click the transfer button to add this time to the list box. This activation list displays the times at which automated sessions are scheduled to start. 266 System Management Guide Managing Message Partner Profiles Note To start a session automatically, you can combine the criteria of "number of messages queued" together with a specified time. For example, you can specify that the session is to be started when ten messages are queued, or at 10:00, 11:00, 12:00, and so on. This setting would result in the following: • if before 10:00, ten messages are queued, a session is started • at 10:00, a session starts • a session starts between 10:00 and 11:00 each time that more than ten messages are queued • a session starts at 11:00 • and so on. 21.9.2.4.2 Defining the Connection Point for Manual Output Sessions To define the connection point for manual output sessions: 1. Click the Session initiation button in the Profile tab and select Manual. 2. In the Output path name field, type the name of the directory where the message and parameter file (if required) has to be placed. The message file and parameter file (if required) are placed in this directory when the session is complete. Example: • on Windows: C:\output\* • on UNIX: /tmp/output/* A character-matching file filter starts immediately after the last slash in the string. The purpose of this filter is to ensure a level of authorisation on the names of parameter files. You use this part of the field to specify a file pattern. The actual parameter file name is selected explicitly at session runtime - in the Start/Run Session window. In the example shown above, the asterisk (*) is used as a file pattern. This is the system default and it specifies that no file pattern constraints have been made. In such a case, the filename of the parameter file specified at session run time can follow any convention that you select. You can also use the filter to specify just part of the proposed name of the parameter or message file. For example, this can be used to ensure that files are generated with a particular extension: Example: • on Windows: C:\output\*.msg • on UNIX: /tmp/output/*.msg This pattern would ensure that message files are generated with the extension .msg. 3. Click the Data format button and select the message format that you require. Select from: • CAS • DOS-PCC 15 July 2011 267 Alliance Access 7.0.20 • RJE • MERVA/2 • XML If you select CAS, then proceed to step 4. If you select XML, then proceed to step 6. For more information about the available formats, see Appendix D, "Message Formats Used in AI" on page 411. 4. When you select CAS, two additional buttons appear, called Subformat and CAS version. Appendix D, "Message Formats Used in AI" on page 411 illustrates each of the available formats. Select a Subformat. The following options exist: • Network Dependent, to specify that messages are to be transmitted in a format used by SWIFT • Network Independent, to specify that messages are to be transmitted in a network independent format. 5. For CAS version, you must decide between CAS 1 and CAS 2. If you select version 2, then the Transfer PKI Signatures and Always Transfer MAC/PAC fields are available. Back-office applications must be ready to receive and store PKI signatures. For an introduction to the CAS protocol in AI, see "CAS Protocol" on page 574. 6. When you select XML, additional menus appear. In the Version menu, the following option exist: • 1 • 2, to exchange files containing MT messages, XML-based messages, File messages, or a mixture of these in the same file. If you select version 2, then the Always Transfer MAC/PAC field becomes available. In the Revision menu, the following options exist: • Original, the base version of the schema. • 1, the revised version of the schema • 2 (minimum revision required to exchange FileAct messages) • 3 (needed to make use of the latest SWIFTNet features) Activating the Local Transfer Agent (LTA) After a batch output session is completed, the subsequent message and parameter files are generated and placed in the file system as specified in the Output path name field. Alliance Access allows you to specify the name of a user-defined executable which is run after completion of the session. This executable can, for example, handle the message file across the communication network. 268 System Management Guide Managing Message Partner Profiles You, as a user, are entirely responsible for the content and the behaviour of this executable. The Local transfer command field is provided for the user to supply the name of the executable. When a batch script file is used, the following specific syntax must be applied: Example: cmd /Q /C start /B /WAIT /MIN <Drive letter>: \batch\lta.bat A separate field Parameters is also provided where parameters for the executable file may be included. Example: -o -copy_to_dir Note: Alliance Access automatically appends the name of the parameter or message file as the last argument in this field. There are two configuration parameters, managed in the System Management application, which govern the relationship between the LTA program and the output session: • Batch Output - LTA Timeout: this parameter contains a time value (in minutes) for the maximum duration of the LTA program. If the LTA waiting mode parameter is activated, then the LTA program is closed (if it has not already done so naturally) after this time has elapsed. • Batch Output - LTA waiting mode: this parameter activates or deactivates the forced closing of the LTA program. If this parameter is activated, then the LTA program is terminated after the period specified by the LTA Timeout parameter. If this parameter is set to ON, then it is good policy to include the command exit at the end of the .bat script. In this way, the session is closed promptly after the script has completed. For more information about these two parameters, see "Configuring System Parameters" on page 158. 21.9.2.4.3 Defining the Connection Point for Automated Input Sessions Overview Automated input sessions are started by the input polling mechanism. The <connection point> part of the Input path name field specifies the directory where existing message or parameter files can be found. The polling mechanism checks the directory specified in the Input path name field at regular intervals. The polling timer parameter is set using the System Management application and defines the time interval between polling operations. If a file is present and no session is currently active, then the `auto-start' process starts an input session. Following a successful input session the messages are routed, and then the batch file (and parameter file if used) is moved into the `FTAbackup' directory. This directory is specified in the Batch Input - Automatic Backup Directory configuration parameter. For more information about configuration parameters, see "Configuring System Parameters" on page 158. Note Automated sessions cannot be run on the Workstation machine. Error Log File When an automatic batch input session fails, an error.log file is generated. It contains: • the session number • the sequence number • text describing the error. 15 July 2011 269 Alliance Access 7.0.20 The batch error file can be found in the directory determined by the configuration parameter MXS - Automatic - Error Directory. 21.9.2.4.4 Defining the Connection Point for Manual Input Sessions To define the connection point for manual input sessions: 1. Click Input path name in the Profile tab and type the name of the directory where the parameter file or message file is located. When connected by means of a Workstation, the Input path name field contains the default path. To browse to a different location, first clear this field. 2. You do not have to specify any more data in this tab. Note When selecting the DOS-PCC message format, specify the disk device files of Alliance Access using DOS notation. Examples of input path names Example of an input path name: • on Windows: C:\tmp\input\* • on UNIX: /tmp/input/* A character-matching file filter starts immediately after the last slash in the string. The purpose of this filter is to ensure a level of authorisation on the names of message or parameter files. It is designed so that you specify a file pattern in this field first, and the required file name explicitly at session runtime in the Start/Run Session window. In the example shown above, the single asterisk (*) is used as a pattern. This is the system default and its practical effect is that no constraints are placed on the file name. You can also use this filter to specify just part of the name of the parameter or message file. For example, this can be used to ensure that only files with a particular extension are accepted. Example of an input path name using a file extension: • on Windows: C:\tmp\infiles\*.par • on UNIX: /tmp/infiles/*.par Using this pattern would ensure that only parameter files with the extension .par are accepted. The output of this filter is taken as the input to a file selector which is available from the Start Session window. Here you are presented with all files in the specified directory which match the file pattern that you specified in Input path name. 21.9.3 Interactive Connection Method Overview The Interactive connection method is used to transfer messages of a specified format between Alliance Access and a message partner. This transfer is carried out according to Common Application Server (CAS) standards. The concepts of the Interactive connection method are described in detail in Appendix F, "Connection Methods in AI" on page 553. 270 System Management Guide Managing Message Partner Profiles To select Interactive as a connection method: 1. Select one of the following directions from the Allowed direction drop-down list: • To Message Partner • From Message Partner • To & From Message Partner 2. In the Profile tab, select Interactive from the Connection method field. Additional fields appear in the Profile tab. 3. Type a value for the required message window size in the Window Size field. The window size determines how many messages may be transmitted before a logical reply is required. This value is used for as long as the session is active. The default value is 1, the maximum window size is 16. If the window size is not valid, that is, not within the valid range, then the session is aborted. More information about interactive window size is provided in Appendix F, "Connection Methods in AI" on page 553. Note: this field is only displayed when the CAS 2 protocol is selected. With the CAS 1 protocol, the messaging window size is 1. The Data format field displays the current message format used in the session. 4. Select the Priority used for transmitting the message. Select a session priority from between 0 and 9. The highest priority is 0, the lowest priority is 9. The default value is 5. The Application Interface uses level of priority to specify the order in which messages in concurrent output sessions are taken from exit queue(s) and transmitted to the message partner. The session priority is significant only when more than one output session is active and when the window size is greater than 1. 15 July 2011 271 Alliance Access 7.0.20 5. From the Subformat field, select the network format that you require. The options are: • Network Dependent, to input/output files containing messages in a format recognised by the SWIFT network • Network Independent, to input/output files containing messages in a format recognised by non-SWIFT networks, such as CHIPS, and SIC 6. Select the required version of the CAS protocol from the CAS version field. Choices are 1 or 2. If you select version 2, and the Allowed direction is To Message Partner or To & From Message Partner, then the Transfer PKI Signatures and Always Transfer MAC/PAC fields becomes available. Back-office applications must be ready to receive and store PKI signatures. 7. From the CAS encoding field, select the required CAS encoding method. The options are: • ASN.1 (only method for CAS1 and default for CAS2) • Text (only available for CAS 2) 8. From the Can be started by field, select the party that is allowed to start a session. The options are: • By Operator: Only an Alliance Access operator can start a session. • By Message Partner: Only a message partner can start a session. • By Operator & Message Partner: Either party can start a session. When starting a session, the selection in the Can be started by field determines which party must listen for an open session request. For example, if the session can only be started by the message partner, and if the message partner profile is enabled, then Alliance Access must listen constantly for an incoming request from the message partner. For a TCP/IP connection, the Connection Id field specifies the port number that the listener must monitor for an open session request. 9. From the Protocol field, select TCP/IP. The Transmission Control Protocol/Internet Protocol (TCP/IP) is used to communicate with host systems that support TCP/IP sockets. For more information about the hardware environment of your system, consult your Alliance Access system administrator. 10. In the Connection Id field, specify the connection identifier. A TCP/IP connection identifier identifies a message partner. The name of each connection identifier that used in the system must be unique. Tip If you need more than five CAS interactive message partners, then manually update the C:\Windows\system32\drivers\etc\services file (on Windows), or the /etc/services file (on UNIX). If Alliance Access is operating in a cluster environment, then you must update these files on both nodes of the cluster. For more information about these files, see "TCP/IP connection identifier" on page 274. 272 System Management Guide Managing Message Partner Profiles 11. The hostname of the message partner must be supplied. This field accepts a maximum of 31 characters. This field is only displayed if you selected By Operator or By Operator & Message Partner in the Can be started by field. The hostname of the message partner must be included, together with its IP address, in the /etc/hosts file of the machine where Alliance Access is installed. 12. Type the name of the local Receive transaction program in the Local RECEIVE TP Name field. This field is mandatory in all cases. 13. If you selected By Operator or By Operator & Message Partner in the Can be started by field, then type the name of the remote Receive transaction program in the Remote RECEIVE TP Name field. When Alliance Access starts the session, it allocates a conversation with the remote RECEIVE tp, the message partner then allocates a second conversation with the local RECEIVE tp. 14. Type the name of the local send transaction program in the Local SEND TP Name field. This field only requires mandatory input if you selected By Operator or By Operator & Message Partner in the Can be started by field. When the message partner starts the session, the message partner allocates a conversation with the local SEND tp, and a second conversation with the local RECEIVE tp. 15. Next, set the session opening authentication keys (session keys). Session keys form an optional session authentication feature which safeguard the session from fraudulent setup. The session authentication process is a peer-to-peer process intended to verify the identity of the session initiator, that is, the sender of the OpenRequest or OpenConfirm Session Protocol Data Unit (SPDU). For more information about what happens at session invocation, see Appendix F, "Connection Methods in AI" on page 553. 16. To specify that you require session authentication, check the Session authentication required option. Use this option to activate session authentication between the Application Interface and the message partner. When this option is selected, a second button appears which allows you to distinguish between unidirectional and bidirectional keys. When one key is used to authenticate Session Protocol Data Units (SPDUs) sent, and another key is used to validate the authentication of SPDUs received, then each key is known as a unidirectional key. When the same key is used to both authenticate SPDUs sent, and to validate authenticated SPDUs received, then the key is known as a bidirectional key. The SPDU is authenticated by an algorithm which uses a secret key - the access key. The result of the authentication check is placed in the SPDU, and upon reception, AI reauthenticates the SPDU using the same access key as the message partner. There is only one access key per message partner. 17. If you selected Session authentication required, then a panel appears which allows you to distinguish between unidirectional and bidirectional keys. Select either: • Unidirectional, to use different keys to authenticate sessions to and from the message partner. Go to step 18 to proceed. • Bidirectional, to use the same key to authenticate sessions to and from the message partner. Go to step 19 to proceed. 15 July 2011 273 Alliance Access 7.0.20 18. In the Send Key field, type the session key used to authenticate an OpenRequest or an OpenConfirm SPDU (Service Protocol Data Unit) sent. The two parts together form a 32character hexadecimal string. Complete the fields in the Send Key panel as follows: • In the First part field, type the first 16 characters of the send key. • In the Second part field, type the second 16 characters of the send key. In the Receive Key field, type the session key used to validate the authentication of an OpenRequest or an OpenConfirm SPDU received. The two parts together form a 32character hexadecimal string. The receiver of the SPDU must use the same key string as the sender or the authentication process fails. Complete the fields in the Receive Key panel as follows: • In the First part field, type the first 16 characters of the Receive key • In the Second part field, type the second 16 characters of the Receive key. 19. In the Send/Receive Key field, type the session key used when sending or receiving an OpenRequest or an OpenConfirm SPDU. The two parts together form a 32-character hexadecimal string. The receiver of the SPDU at either side must use the same key string as the sender or the authentication process fails. Complete the fields in the Send/Receive Key panel as follows: • In the First part field, type the first 16 characters of the key • In the Second part field, type the second 16 characters of the key. If session authentication fails, then the session is aborted and an error event is generated. TCP/IP connection identifier The TCP/IP connection identifier refers to an entry in the following file, which associates the services with a logical port number: • On windows: C:\Windows\system32\drivers\etc\services • On UNIX: /etc/services At installation time, five connection identifiers are defined in your services file: MPconn1 MPconn2 MPconn3 MPconn4 MPconn5 5101/tcp 5102/tcp 5103/tcp 5104/tcp 5105/tcp The connection identifier is the string in the left-hand column, for example, MPconn1. The righthand column specifies the logical port number and protocol type associated with that port. The port number is used on both sides of the connection, that is, the system on which Alliance Access is running, and the system on which the message partner is running. When Alliance Access or a message partner starts a session, the other side must "listen" to the correct port for an incoming request. Important 274 If you change a port number, for example, 5101, then you must inform the relevant message partner about the change. System Management Guide Managing Message Partner Profiles 21.9.4 WebSphere MQ Connection Method Overview The WebSphere MQ method allows for the exchange of messages using IBM WebSphere MQ between Alliance Access and a message partner. Before you use the WebSphere MQ Host Adapter for the first time, you must configure some environment variables, as described in "Configuration of WebSphere MQ" on page 616. For more information about the WebSphere MQ connection method, and also how it exchanges information over FileAct, see "WebSphere MQ" on page 616. To define the WebSphere MQ connection method: 1. Select one of the following directions from the Allowed direction drop-down list: • To Message Partner • From Message Partner 2. In the Profile tab and select the connection method WebSphere MQ. 3. From the Data format drop-down list, select either: • MQ-MT - default value • XML - Select the Revision from: Original, 1, 2, or 3. Note Original is available only if you select Use MQ Descriptor, or if Transfer SAA Information is not selected. Select Revision 2 or 3, if you are defining the message partner profile to exchange information over FileAct. For more information, see step 10 on page 278. 15 July 2011 275 Alliance Access 7.0.20 4. If you selected To Message Partner, then you can select the following options, if required and appropriate: Purpose, if selected for: Parameter 5. MQ-MT XML Transfer PKI Signatures To transfer PKI signatures when sending FIN messages to this message partner. Back-office applications must be ready to receive and store PKI signatures. Not available for selection. PKI signatures are always transferred for XML version 2. Always transfer MAC/PAC Alliance Access adds a dummy value (00000000) if a back-office application requires MAC/PAC trailers but the message does not contain them. This option supports back-office applications that require MAC/ PAC trailers. In the Session initiation field, select either: • Manual, if you want an operator to start a communication session with a message partner • Automatic, if you want the communication session with the message partner to start automatically. The Alliance Access servers must be running and the message partner enabled. Automatic sessions cannot be run on the Workstation machine. If you select Automatic, and the Allowed direction is: – "To Message Partner" - the Run Output session panel becomes available. – "From Message Partner" - the Keep Session Open option is selected automatically. 6. Enter the names of the following items, or leave the fields blank to use their default values: • Queue Manager Name - the name of the WebSphere MQ queue manager where the WebSphere MQ queue is defined • Queue Name - the name of the WebSphere MQ queue • Error Queue Name - the name of the MQ Error queue. If you leave this field empty, then the default error queue is used. You can enter names of up to 48 characters in length. Note 276 If you do not specify the Queue Manager Name and Queue Name, then you can create a message partner profile, but you cannot enable it. You must add values in these fields before you can enable the profile. System Management Guide Managing Message Partner Profiles 7. Parameter Transfer SAA Information Purpose, if selected To transfer information about the Alliance Access instance which has processed the message When you select this option, the Use MQ Descriptor field appears. Notes The information includes: • the Alliance Access instance name followed by / • either: – exit point that the message was taken from (emission profile) – the routing point where the message ended reception profiles (reception profile) • the owner of the Alliance Access instance • the unit to which the message belongs Use MQ Descriptor 8. To send the Alliance Access information in the MQ Message Descriptor to the message partner If you clear this option, then the MQ Message Data part carries the Alliance Access information. For more information, see "MQ Message Descriptor" on page 623. If you select Keep Session Open, then Alliance Access automatically recovers a failed connection with WebSphere MQ. For more information about recovery of the WebSphere MQ connection method, see "Recovery of a WebSphere MQ Connection" on page 631. 9. Use the Run Output Session panel to define how you want the session to start, by specifying either: The number of messages that are queued at the assigned exit point(s) In the Number of messages = field, type the number of messages that must be queued to trigger a session. One or more specific times of the day In the Or at (hh.mm) field, enter the time at which the automated sessions must start. After you specify a start time, click the transfer button to add the time to the list box. You can add several times. The activation list displays the times at which automated sessions are scheduled to start. To start a session automatically, you can combine the criteria of "number of messages queued" together with a specified time. For example, you can specify that the session must start after ten messages are queued, or at 10:00, 11:00, and 12:00. This setting would result in the following: • if ten messages are queued before 10:00, then a session starts • at 10:00, a session starts • a session starts between 10:00 and 11:00 each time that ten or more messages are queued • a session starts at 11:00, and so on 15 July 2011 277 Alliance Access 7.0.20 10. If you are defining the message partner profile to exchange information over FileAct (using Revision 2 or 3 of XML version 2), then configure the following parameters as appropriate: Parameter FileAct mode Value Select from: To Message Partner From Message Partner ✓ ✓ • Full (Default) - to transfer both the XMLv2 message and the FileAct payload over WebSphere MQ between the back-office application and Alliance Access • Mixed - to transfer the XMLv2 message between the back-office application and Alliance Access over WebSphere MQ and to transfer the FileAct payload over the local file system. For more information about the FileAct mode, see "FileAct over WebSphere MQ" on page 630. 278 Chunk Size If you selected Full FileAct mode, then specify the maximum size of a WebSphere MQ message (in bytes) that Alliance Access can send a back-office application. To set this value, see "FileAct over WebSphere MQ" on page 630 or refer to the guidelines provided in the IBM WebSphere MQ documentation. Default value: 32768 bytes ✓ x Don't Use Segmentation If you selected Full FileAct mode, and the payload of the file is greater than the Chunk Size, then clear this option to ensure that the payload file is segmented before it is sent to the back-office application. If you select this option, then MQ grouping is used and MQ segmentation is not used. For more information about the WebSphere MQ segmentation, see the WebSphere MQ documentation. ✓ x Input Attachment Directory If you selected Mixed FileAct mode, then specify the path to a directory on the server where the payload file is stored The exact payload file name will be extracted from the content of the XMLv2 message. x ✓ Output Attachment Directory If you selected Mixed FileAct mode, then specify the path to a directory on the server where the payload file is stored The exact payload file name will be extracted from the content of the XMLv2 message. ✓ x System Management Guide Managing Message Partner Profiles Next, complete the parameters in the following tabs: • To Message Partner - Emission tab. See "Specifying the Emission Parameters" on page 281. • From Message Partner - Reception tab. See "Specifying the Reception Parameters" on page 285. • Authentication tab, if required. See "Specifying Local Authentication" on page 291. 21.9.5 SOAP Connection Method Purpose The SOAP connection method enables the exchange of MT, XML-based messages, and FileAct messages between Alliance Access and back-office applications using the SOAP protocol. The SOAP connection method requires the licence package 14:SOAP ADAPTER and supports only the XMLv2 data format. Before you begin Identify the value to use for the Window size field. The window size determines: • in case of emission by the back-office application, the maximum number of consecutive messages that can have their past acknowledgement replayed or are being sent. The count starts from the next expected message. • in case of reception by the back-office application, the maximum number of messages that are still waiting for the back-office application to acknowledge them For more information, see "Window Size" on page 596. To define the SOAP connection method: 1. Select one of the following directions from the Allowed direction drop-down menu: • To Message Partner • From Message Partner • To & From Message Partner 2. In the Profile tab, select the SOAP connection method. Additional fields appear in the Profile tab. The Data format field displays the current message format used in the session. 15 July 2011 279 Alliance Access 7.0.20 The data format is always XMLv2 for message partner profiles that use SOAP: 3. Type a value for the required message window size in the Window Size field. 4. Select the Revision from: • 2 • 3 5. If you are defining the message partner profile to exchange information over FileAct, then configure the following parameters as appropriate: Parameter FileAct mode Value Select from: To message partner From message partner ✓ ✓ x ✓ • Full (Default) - to transfer both the XMLv2 message that contains the filetransmission parameters and the FileAct payload over SOAP • Mixed - to transfer the XMLv2 message that contains the file-transmission parameters over SOAP and to transfer the FileAct payload over the local file system. For more information about the FileAct mode, see "SOAP" on page 587. Input attachment directory 280 If you selected Mixed FileAct mode, then specify the path to a directory on the server where the payload file is stored. System Management Guide Managing Message Partner Profiles Parameter Value To message partner From message partner The exact payload file name will be extracted from the content of the XMLv2 message. 6. Output attachment directory If you selected Mixed FileAct mode, then specify the path to a directory on the server where the payload file is stored. The exact payload file name will be extracted from the content of the XMLv2 message. ✓ x Extension If you selected Mixed FileAct mode, then you can optionally specify an extension of the payload file. ✓ x Select the FIFO option, to specify that Alliance Access receives the messages from the back-office application to be added in First In First Out (FIFO) order. This option appears when you select From Message Partner or To & From Message Partner. Next, complete the parameters in the following tabs: • To Message Partner or To & From Message Partner - Emission tab. See "Specifying the Emission Parameters" on page 281. • From Message Partner or To & From Message Partner - Reception tab. See "Specifying the Reception Parameters" on page 285. • Authentication tab, if required. See "Specifying Local Authentication" on page 291. 21.10 Specifying the Emission Parameters Overview Emission parameters apply only to output sessions. There are three operations to be addressed in the Emission tab: • assigning exit point(s) to the message partner • specifying the emission format for messages using the CAS, MQ-MT, or XML version 2 data formats • specifying the content of any notification instances Emission parameters are set in the Emission tab. For a description of the fields displayed in this tab, see "Emission Tab" on page 281. 21.10.1 Emission Tab Description This tab is available when you select To Message Partner or the To & From Message Partner tab in the Allowed direction field of the Profile tab. 15 July 2011 281 Alliance Access 7.0.20 The fields that are available in the Emission tab depend on the connection method and data format that you select in the Profile tab. Example of Emission tab Field descriptions Exit Points Select the exit points where the messages for sending are located, as follows: • Selected - displays the exit points that are assigned to this message partner. • Available - displays all exit points which are not currently assigned to this and other message partners. Routing code transmitted Select this option, to transmit the routing code to the message partner. The routing code is specified in the routing rules for the routing point that is associated with the Exit point. For more information, see "Routing Code Trailer" on page 541. Message emission format Only displayed for messages using the CAS, MQ-MT, or XML version 2 data formats. 282 System Management Guide Managing Message Partner Profiles Select: • Complete Text to output headers and text in non-expanded layout, for example: :20:12345 :32A:011212USD10000, :50:John :59:Jim • Expanded to output headers and text. Only the message text is in expanded layout, for example: 20: transaction reference number: 12345 32A: value date, currency and amount Date: 12 December 2001 Currency: USD (US DOLLAR) Amount: - #10,000.# 50: ordering customer: John 59: beneficiary customer: Jim Notification emission • Send original message - used to include the original message in the notification message. For more information, see "Specifying the Notification Content" on page 284. • Format of original message - used to select a format for the original message. For more information, see "Specifying the Notification Content" on page 284. Transfer UUMID If you select this option, then Alliance Access transfers the UUMID with the message to the message partner. This option is only available for the data format MQ-MT. Include TRN Select Include TRN to send the transaction reference number of the original message to the message partner. This option is only available for the data format MQ-MT, and if Send Original Message is not set to Always. Remove S-Block Select Remove S-Block to remove the S-Block from the MQ Message Data part of the message, which is transferred over FileAct to the message partner. The S-block is also removed from the original message if it is transferred. This option is only available for the data format MQ-MT. Include all FIN blocks Select this option for FIN messages, to include all the FIN blocks (Block 1, 2, 3, 4, and 5) in the Body element of the XML version-2 message. If you do not select this option, then only the FIN block 4 is included in the Body element of the FIN message. The blocks are base-64 encoded. This option appears if you select revision 3 of XML version 2. 21.10.2 Assigning the Exit Point To assign an exit point to a message partner: 1. 15 July 2011 Locate the list Available. This list contains all exit points which are available for assignment to this message partner. 283 Alliance Access 7.0.20 2. Select the required exit point, and then click transfer button to move it to the Selected list. If you select the Add or Modify menu option, then the selected exit point(s) are assigned to the message partner. Note All default exit points (exit queues) are described in Appendix C, "Queues and Message Processing Functions" on page 394. 21.10.3 Specifying the Message Emission Format Overview The Message emission format button is used to specify the format of the message sent to the message partner. This appears for connection methods, File Transfer, Interactive, and WebSphere MQ. The setting refers only to original messages and copies in CAS NIF, MQ-MT, and XML version 2 formats. Click the button and select from the following: • Complete Text: send the header and the message text in NIF, MQ-MT, or XML (version 2) format • Expanded: send the message text in NIF, MQ-MT, XML version 2, or network output format (SWIFT). Only the message text is in expanded layout. For an example of expanded text, see "Message emission format" on page 282. When using connection method WebSphere MQ with data format XML version 2, this option has no effect. 21.10.4 Specifying the Notification Content Overview These Notification emission fields specify whether to append the original message to the notification, and if so, in what format. The Notification emission comprises two fields: • Send original Message • Format of original Message - only used for messages in MQ-MT or XML format. To specify the notification content: 1. The Send original message field is used to specify whether the text (block 4) of the message is to be added to the notification. Select from the following options: • When created by another Message Partner: when a notification instance is required by a message partner other than the creator of the message, the original message is included. • For example, such message partners may be a group of individuals within a bank delegated to reconcile network acknowledgements received for each individual message sent. For this purpose, they need a copy of the message. • When message modified: include a copy of the original message if the message is modified in any way. 284 System Management Guide Managing Message Partner Profiles • Always: include the original message with all notifications. • Never: do not include the original message with any notification. The headers of the original message are always included. 2. The Format of original message field is used to specify how much content of the original message is included in the notification. This field applies when Send original message has a value that is not Never. Select from the following options: • Headers only: send only the header • Complete Text: send the header and the message text • Expanded: send the header and the message text. Only the message text is expanded layout • Minimum Info: send minimum information needed for traffic reconciliation with the message partner. This option is only available for the XML version 2 data format. The information provided is based upon the following attributes of the message: – format – sub-format – sender address – original receiver address. 21.11 Specifying the Reception Parameters Overview Reception parameters apply only to input sessions. This tab is used to establish the following parameters: • default validation level applied to the message • permission profile governing the actions that can be applied to the incoming message • default message modification permission • unit to which the message is assigned • validation mode to be applied to batch files • message partner reconciliation setting • default message disposition For a description of the fields displayed in this tab, see "Reception Tab" on page 286. 15 July 2011 285 Alliance Access 7.0.20 21.11.1 Reception Tab Description This tab is available when you select From Message Partner or the To & From Message Partner tab in the Allowed direction field of the Profile tab. The fields that are available in the Reception tab depend on the connection method and data format that you have selected in the Profile tab. Example of Reception tab Field descriptions Validation level Select the level of validation that you want performed on the text block of each input message. For more information about the validation levels, see "Levels of Validation" on page 544 and Appendix E, "Message Validation and Disposition" on page 543. Profile name Select a security definition profile. The entitlements and permissions of this profile allow the message partner profile to create and route input messages within Alliance Access. Note The creation of messages by a message partner is subject to the restrictions that are defined in the SDA profile that is assigned to the message partner, and not the profile assigned to the operator who starts a session under Application Interface. The default profile MsgPartner allows: • all message destinations • all message types (MTs) 286 System Management Guide Managing Message Partner Profiles • all message currencies • permission to bypass message verification • permission to bypass message authorisation You can use MsgPartner as a template for additional message partner profiles with different permissions. Message modification allowed Select Allowed or Prohibited, to indicate whether the text of input messages can be modified within Alliance Access. Selecting Allowed allows an operator to modify messages that have failed validation. Messages that are in CAS format can have a Modify Allowed flag which overrules this field, if it is present. If the configuration parameter Common Ref Calculation is set to No, then Alliance Access does not calculate the Common Reference in field 22. In this case, the Message modification allowed is ignored. Unit to be assigned Use this field to select the unit to which all incoming messages are assigned when using this profile. UUMID included in Original Message If you select both WebSphere MQ as a connection method, and MQ-MT as a data format, then you can select this option to include a UUMID in the original message to be sent. Create repair message If you select WebSphere MQ as a connection method, and if you have licence option 07:STANDALONE REC, then you can select this option to specify whether a stand-alone Alliance Access system may create a repair message upon reception of a transmission notification. This field only appears if you have licence option 07:STANDALONE REC. Batch File validation If you select File Transfer as a connection method, then select one of the following options to specify whether the transfers continue if validation errors occur during input: • Abort on Rejection aborts a session if an error occurs. The file is moved into the "FTAError" directory and an event is recorded in the Event Journal. • Continue on Rejection continues a session if an error occurs. The file transfer continues if: – The length of the message is not valid – Block 4 contains content that is not valid – A checksum error occurs – A disposition error occurs. Build unique file transfer reference If you select File Transfer as a connection method, then select this box to attach a unique reference to the ACKs and NAKs that are received back from SWIFT in response to the input messages. The references allow the back-office application to reconcile the messages that it has sent to SWIFT with the acknowledgements that it receives from Alliance Access. 15 July 2011 287 Alliance Access 7.0.20 The reference is included as part of the S block of the ACK or NAK, and contains the following: • input file name • sequence number of the message • number of messages in the input file The unique message reference is constructed as follows: <Input batch filename>/<sequence number of the message>/<number of messages in the batch file> Note The maximum permitted length of the generated reference is 46 characters. Therefore, to avoid the session aborting with the error "File name too long", limit the length of the file name to 32 characters, as described in the Daily Operations Guide. Disposition The Disposition field is used to determine the default message disposition to be applied to messages during an automatic input session. It is used together with the Message in field. If Route is selected, then the current routing rules at AI_from APPLI handle the message. Report Format This option is available only for the WebSphere MQ connection method with the data format MQ-MT. Selecting one or several of the following items allows you to include them in a report message: • Transfer UUMID - Alliance Access transfers the UUMID with the message • Original Message - Alliance Access appends the original message request to a notification • Validation Error Code - Alliance Access includes an error code in a response message if an error occurred during processing. 21.11.2 Message Disposition Overview The Disposition field is used to determine the default message disposition to be applied to messages during an input session. When an automatic CAS input session is in progress, the message APDUs field dispositionState or targetApplicationRule may not be present in the message, in which case the default message disposition specified here is used. For more information, see Appendix E, "Message Validation and Disposition" on page 543. Click the Disposition field to select one of the following: • Dispose: Dispose the messages in the message preparation queues as specified by the message in field. The message in field is used to select the queue to which a message is to be disposed. This is only used when the Dispose option is selected. Available queues are: – Modification (MP_mod_text) – Verification 288 System Management Guide Managing Message Partner Profiles – Authorisation – Ready-to-send • Route: this is the default value for this field. Messages are routed according to routing rules specified at the AI Inbound queue. Security bypasses in the permission profile are disregarded. Note Permission to bypass the verification and authorisation stages is provided by the message partner profile. This becomes not valid when the Route option is selected. 21.11.3 Assigning a Unit Overview You can assign a unit to each input message received from a message partner. To assign a unit to each input message received from a message partner: 1. Click the drop-down list to the right of the Unit to be Assigned field. 2. Select a unit from the list. The unit is assigned to the message before the message is routed or disposed to a queue. The assignment of a unit is not binding, a different unit can be assigned to the message by the routing rules. For more information about assigning a unit, see "Defining Units" on page 78. 21.11.4 Setting the Batch Validation Mode Overview Occasionally, errors occur during the input of a batch file. To prepare for such events, you can use the Batch file validation field to determine whether the session must be closed, or if the session must continue (presuming the error is not a security issue) when these errors occur. The Batch file validation field is only available when the File Transfer connection method is selected in the message partner profile. Click the field and select from: • Abort on Rejection: abort the entire session if any errors occur in validation. If this is an automatic session, then the message file is moved into the `FTAerror' directory and a record is made in the Event Journal application (EJA). • Continue on Rejection: do not abort the session if errors occur which are specific to the following. The errors can be of the following types: – The length of the message is not valid – Block 4 contains content that is not valid – A checksum error occurs – A disposition error occurs. 15 July 2011 289 Alliance Access 7.0.20 When Continue on Rejection is selected, and the message is flagged as modifiable, erroneous messages are passed to the MP_mod_text queue for manual recovery. If the message is flagged as not modifiable, then the message is completed and a record is made in the Event Journal. 21.11.5 Message Partner Reconciliation Overview Use the button Build unique file transfer reference to provide adequate reconciliation information to the message partner. The reconciliation information is an attachment to ACK or NAK notifications which uniquely identifies each message received. The reference is included as part of the S block of the ACK or NAK, and contains the following: • input file name • sequence number of the message • number of messages in the input file Note The unique message reference is constructed as follows: <Input batch filename>/<sequence number of the message>/<number of messages in the batch file> The maximum permitted length of the generated reference is 47 bytes. If this is exceeded, then the batch input session stops. Using the content of the "REF:" trailer, the mainframe application sending the batch file can reconcile the ACK or NAK for each message and notify the originator. There are only two options available from this button: • Yes to build the transfer reference • No to suppress the reference. 21.11.6 Selecting a Permission Profile for the Message Partner Overview The Profile name button is used to select a particular message partner permission profile. The entitlements and permissions of the selected profile are adopted by the current message partner profile. The permission profile is used by the Application Interface to authorise the creation and disposition of messages arriving from message partners (actually, it governs the re-creation and disposition of received messages in the internal Alliance format). At installation time, every message partner receives the default permission profile - MsgPartner. This default profile grants permissions for: • All destinations • All message types (MTs) • All currencies 290 System Management Guide Managing Message Partner Profiles • Permission to bypass message verification. This becomes relevant when the Dispose option is selected from the Disposition field. Note that in the selected profile, it is possible to prohibit or permit the bypass of verification based on messages of certain currencies or/and certain "MTXXX" types. It is not possible to prohibit or permit bypassing verification based on the amount. • Permission to bypass authorisation. Note that in the selected profile, it is possible to prohibit or permit the authorisation of messages of certain currencies or/and certain "MTXXX" types. It is not possible to prohibit or permit bypassing authorisation based on the amount. This profile 'MsgPartner' is not locked - it may be changed with the Security Definition application. In this way, it may be used to permit or deny actions according to the nature of the message partner and its relevance to Alliance Access. Note that the following permissions of the message partner profile are always checked at the creation of a message: • Own destination • Message type • Currency and amount The following permissions of the message partner profile are checked only if you select to dispose the message: • Bypass verify MT • Bypass verify CCY • Bypass auth MT • Bypass auth CCY 21.11.7 Specifying Message Modification Overview Message modification allowed is used to determine whether Alliance Access can modify (or correct) the message text of a message that it receives from a message partner. Generally, these messages have failed text validation. If the field is set to Allowed, then modification is permitted. Otherwise, modification of the text is prohibited. Messages received in CAS NIF/NDF format are an exception to this. A special APDU field, modifyAllowed, exists in a message in CAS NIF/NDF format, which specifies whether the message text can be modified. If this field is not present, then the selected value in the message partner profile is used. If a modify text permission flag is present, then that value overrides the Message modification allowed field. 21.12 Specifying Local Authentication Overview Local Authentication is a process intended to verify two aspects of a transmission: • The identity of message partners • The integrity of the message text. 15 July 2011 291 Alliance Access 7.0.20 The message is authenticated by an algorithm which uses a secret key - the authentication key. The authentication value is placed in the block S of the message and is identified as the Local Authentication trailer. For CAS NDF/NIF formatted messages, it is placed in the Application Protocol Data Unit (APDU) field - apduLocalAuth. For XML formatted messages, it is placed in the Data Protocol Data Unit field - DataPDU, just before the XML declaration. Upon receipt of the message, the Application Interface re-authenticates the message using the same local authentication key as the message partner. There is only one local authentication key per message partner. Local Authentication parameters are set in the Authentication tab. For a description of the fields displayed in this window, see "Authentication Tab" on page 293. Unidirectional and bidirectional keys are both made up of two parts - a first part and a second part. This is done to meet the requirement of users that want to have dual control on the maintenance of local authentication keys for security reasons. The permission to add/modify/ remove the first part of the local authentication key can be granted to one operator whilst the same permission on the second part can be granted to another operator. Other types of keys used in Alliance Access, that is, session keys, and so on, are split in a similar manner to address the same security concerns. If you want to grant individual permissions on each part of the local authentication key, then use the Security Definition application (SDA). If you do so, then two separate operators are required to enter the complete key. What happens when a local authentication error occurs? The session is aborted and an event pointing to a local authentication error is recorded. For batch input sessions this means that if any message in the file fails authentication, the entire batch is aborted and no messages are processed by Alliance Access. In fact, during the batch input session the received messages are placed on the Application Interface inbound queue and reserved. If an authentication error occurs, then the session is aborted, the recovery mechanism frees and deletes the queued messages, and the associated message partner status changes to 'Disabled'. 292 System Management Guide Managing Message Partner Profiles 21.12.1 Authentication Tab Description Local authentication parameters are set in the Authentication tab. Example of Authentication tab Field descriptions Unidirectional Select this option to use different keys to authenticate input and output messages. Bidirectional Select this option to use the same key to authenticate input and output messages. This option is only available when the allowed session direction is To & From Message Partner. Send Key These fields are available when the allowed session direction is To Message Partner or To & From Message Partner. Type a send authentication key and pass it to the back office. The key is used by the back office to check the unique values in the Local Authentication trailers of messages during file output. If the text of these messages is complete, then the unique value is reproduced and the messages pass local authentication. The back office must decide how authentication failures are handled. Receive Key These fields are available when the allowed session direction is From Message Partner or To & From Message Partner. Type the receive authentication key that is provided by the back office. The key is used to check the unique values in the Local Authentication trailers of messages during file input. If the text of these messages is complete, then the unique value is reproduced and the messages pass local authentication. If a single message fails authentication, then the entire file is aborted. The aborted file is moved to the Error directory. 15 July 2011 293 Alliance Access 7.0.20 Send/Receive Key This field is available when the bidirectional key type is selected. The receiver of the messages at either side must use the same key as the sender. 21.12.2 Setting Up the Local Authentication Key To set up the local authentication key: 1. Locate the check button situated in the Authentication tab. 2. If authentication is required, then select Local authentication required. When this option is selected, two additional check boxes appear for to select between unidirectional and bidirectional communication sessions. 21.12.2.1 Unidirectional Overview Unidirectional communication uses two keys: one for authenticating sent messages, the other for supporting the authentication of received messages. For security reasons, each of these keys is subdivided into two halves: • Send Key • Receive Key Note For the WebSphere MQ Connection method, you can select only unidirectional option. Send Key This string of characters is the local authentication key used to authenticate a message sent. The two parts together form a 32-character hexadecimal string (if the data format that you select is XML, see "XML Selected as Data Format " on page 295). The two parts must be entered as follows: • First part: Enter the first 16 characters of the send key. • Second part: Enter the second 16 characters of the send key. The Send Key field appears when the Allowed direction button is set to To Message Partner or To & From Message Partner. Receive Key This string of characters is the local authentication key used to validate the authentication result of a message received. The two parts together form a 32-character hexadecimal string (if the data format that you select is XML, see "XML Selected as Data Format " on page 295). The receiver of the message must use the same key string as the sender or the authentication process fails. The two parts must be entered as follows: • First part: enter the first 16 characters of the Receive key • Second part: enter the second 16 characters of the Receive key. 294 System Management Guide Managing Message Partner Profiles The Receive Key field appears when the Allowed direction button is set to From Message Partner or To & From Message Partner. 21.12.2.2 Bidirectional Send/Receive Key Bidirectional communication uses only one authentication key. This key is used both to authenticate sent messages and to corroborate the authentication of received messages. The Send/Receive Key is the local authentication key that is used when sending and receiving messages. For security reasons, this key is subdivided into two parts, which together form a 32character hexadecimal string (if the data format that you select is XML, see "Rules for Local Authentication key" on page 295). The receiver of the message at either side must use the same key string as the sender or the authentication process fails. With the Send/Receive setting, the sender passes the key to the receiver as an external operation. In fact, it does not matter who produces and passes the key just as long as the two parties are using the same key when a transmission is started. If local authentication fails then the session is aborted and an error event is generated. Complete the parts of the Send/Receive Key as follows: • First part: Enter the first 16 characters of the key. • Second part: Enter the second 16 characters of the key. This bidirectional option is only displayed when the Allowed direction button is set to To & From Message Partner. 21.12.3 XML Selected as Data Format Local Authentication key The following information applies only if you select the data format XML for the File Transfer, WebSphere MQ, and SOAP connection methods. If you change the data format from XML to another data format (for example, to RJE) and vice versa, then the Local Authentication Key fields are emptied. Rules for Local Authentication key The Local Authentication key consists of 32 printable characters and must be entered in two 16character strings. This key must be the same as the one that is entered on the back-office application. Each part of the Local Authentication key must comply with the following password complexity rules: • A string of exactly 16 US-ASCII printable characters (from characters 32 to 126) that include: – A-Z – a-z – 0-9 – ! "# $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ • The key must contain at least one upper-case and one lower-case alphabetic character 15 July 2011 295 Alliance Access 7.0.20 • The key must contain at least one number • The number of occurrences of the same character must be equal to or less than half the number of characters in it, minus one. Note Auto-recognition must not be used for Message Partners with local authentication defined and the data format is XML. 21.13 Modifying a Message Partner Profile Overview This section describes how to modify, disable, enable, and remove a message partner profile. 21.13.1 Modifying a Message Partner Profile To modify a message partner profile: 1. Disable the profile. For details, see "Disabling a Message Partner Profile" on page 296. 2. Make any necessary changes to settings in the profile. When finished, select Modify from the Message Partner menu. It is important to remember to do this before re-enabling the profile. 3. Re-enable the profile. For details, see "Enabling a Message Partner Profile" on page 296. 21.13.2 Disabling a Message Partner Profile Overview To make any modifications to an existing message partner profile, the profile must first be disabled. To disable a message partner profile: 1. Select the required profile from the Message Partner view. 2. Select Disable from the Message Partner menu. The Status attribute displayed in the Message Partner view changes to Disabled. The profile must be re-enabled before it can be used in a communication session. Note When the Disable command is issued during an active communication session, Alliance Access asks whether the profile is to be disabled at the end of the current session. 21.13.3 Enabling a Message Partner Profile Overview After adding or modifying a message partner profile, you must enable the profile before it can participate in a communication session. 296 System Management Guide Managing Message Partner Profiles To enable a message partner profile: 1. Select the required profile from the Message Partner view. 2. Select Enable from the Message Partner menu. The Status attribute displayed in the Message Partner view changes to Enabled. For more information about running and managing a communication session with a message partner, see "Managing Message Exchange Sessions" in the Daily Operations Guide. 21.13.4 Removing a Message Partner Profile Overview When removing a message partner profile, keep in mind the following points: • You cannot remove a message partner profile while it is assigned to an exit point • You cannot remove a message partner profile while it is enabled • All routing rules must be checked to see whether the message partner (keyword "Src_entity") is referenced in the trigger condition criteria. For more information, see "Routing Rules" on page 318. Since the name of the message partner is used for recovery purposes during Alliance Access startup, a message partner may not be removed and re-created with the same name until all messages sent or received by the initial message partner have been archived. Note To remove a message partner profile: 1. Select the required profile from the Message Partner window. 2. Select Remove from the Message Partner menu. A dialog box appears, asking you to confirm the removal. 3. Click Yes to proceed or No to abort the removal. 21.14 Automatic Logical Terminal Allocation Overview Alliance Access provides two ways to balance the FIN traffic over several logical terminals: • When back-office applications send to Alliance Access FIN messages with as sender logical terminal, the code "X", Alliance Access validates the messages with the Message Syntax Table set as default Live or default Test & Training, and then distributes these messages over the logical terminals available for input. The actual logical terminal used to send the messages is logged within the emission appendix of these messages. • Through the System Management application, Alliance Access also provides a facility to automatically allocate a logical terminal to FIN messages independently from the original logical terminal sender: messages received from message partner applications may be transmitted by a logical terminal other that the one specified in the message. In both features, the acknowledgement message returned to the message partner application may also not match that of the sender logical terminal. 15 July 2011 297 Alliance Access 7.0.20 If the message partner uses the sender logical terminal for message reconciliation rather than the destination, then errors in the back-office application may result. Automatic logical terminal allocation must not be used in this case. Users that already have a back-office application that implements load balancing may experience a negative impact on performance and must ensure that the LT load balancing parameter is turned off. 21.15 Typical Configurations for Message Exchange Sessions Overview The number of message partner profiles needed for your operation depends on how you want to use the Application Interface. The following is a list of four common configurations: • Configuration 1: The need to run batch sessions with the same message partner one at a time. • Configuration 2: The need to run batch sessions with more than one message partner at a time, together with the need to perform message search in the Message File application (MFA), based on the names of message partner profiles. • Configuration 3: The need to keep input and output batch files in separate locations. • Configuration 4: The need to run interactive sessions using the CAS protocol. 21.15.1 Configuration 1 Overview If you only need to run manual batch sessions one at a time, then you can confine yourself to using a single message partner profile. In this profile, the connection method specifies that Allowed direction is set to To & From Message Partner, so at session establishment time, you have to be more specific about the session direction and specific message file. ep1 Profile: mp3 "To and From..." D0540056 Application Interface inbound With this method, there is only one profile for each message partner, however you can use the Output path name field to specify the destination of output messages (to message partner) and the Input path name field to specify the location of input messages. 298 System Management Guide Managing Message Partner Profiles 21.15.2 Configuration 2 Overview If you want to run a batch input session and a batch output session concurrently, then you must create separate input and output profiles. Using a separate profile for each message partner can also help you to search and locate a message in the message file, for example, a search using the Message File application based on the attribute field "Session Holder". In the output profile, the Allowed direction field is set to To Message Partner and in the input profile, this field is set to From Message Partner. At session run time, you only have to specify the name of the message file. Application Interface inbound Application Interface outbound Profile: Input _mp2 "From..." mp1 mp2 D0540057 Profile: Input _mp2 "To..." Profile: Input _mp1 "From..." In the example above, the input and output profiles are: • Input_mp1 and Input_mp2 • Output_mp2. Note You cannot have batch sessions with the same message partner concurrently, that is, transmit and receive messages in the same session. 21.15.3 Configuration 3 Overview If you want to keep input and output batch files in separate locations, then you can use the same configuration as described in "Configuration 2" on page 299, with the following additions: • For input, specify the required input directory on your file system in the Input path name field of the Profile tab. • For output, specify the required output directory on your system in the Output path name field of the Profile tab. 21.15.4 Configuration 4 Overview The Interactive connection method enables the concurrent transmission and reception of messages with a message partner. For this bidirectional communication, you only need one profile, but remember that the Allowed direction must be set to To & From Message Partner. 15 July 2011 299 Alliance Access 7.0.20 Application Interface inbound Application Interface outbound Profile: Interactive "To and From..." D0540059 Message Partner 21.16 Configuration for Sanctions Screening over SWIFT Overview This section provides an overview of the configuration tasks that are required before Alliance Access can support the screening of messages as part of Sanctions Screening over SWIFT. For more information about how Sanctions Screening works, see the Sanctions Screening over SWIFT Service Description. Possible results of sanctions screening When the Sanctions Screening over SWIFT service processes a message, the following results are possible: • The message does not generate an alert (field tag 433:/AOK). • A string in an MT message matches an element of your selected sanctions list. In this case, the result is one of the following: – False positive (field tag 433:/FPO) Sanctions Screening generates an alert that your compliance officer investigates, and then authorises message delivery. – True hit (field tag 433:/NOK) Sanctions Screening generates an alert that your compliance officer investigates, and then confirms as a true match with the element of the sanctions list. Warning message for a true hit If the message is a true hit, then the field tag 433 in block 3 of an MT message contains 433:/ NOK. You can view the warning message through a message search and message print: • message search The Message Details - Header tab displays the following warning message: Sanctions screening - Message blocked. Depending on the value of the configuration parameter Display/Print FIN User Header, the Message Details - Text tab displays block 3 of MT messages. • message print 300 System Management Guide Managing Message Partner Profiles The first sentence of the warning header contains the following: Sanctions screening Message blocked. Depending on the value of the configuration parameter Display/Print - FIN User Header, the printed report of the Message Details displays block 3 of MT messages. Configuration tasks 1. Change the value of the configuration parameter, Display/Print - FIN User Header to always display block 3 in the Message details, and to always print block 3. For more information about the configuration parameters, see "Display/Print" on page 164. 2. You can define conditional routing rule using the keyword FIN_user_header to route any message that Sanctions Screening over SWIFT flags as a true hit. For more information about message keywords, see "List of Message Keywords" on page 331. 15 July 2011 301 Alliance Access 7.0.20 22 Managing Exit Point Profiles Introduction This section describes how to use the Application Interface to set up exit point profiles, and to assign them to message partners. You can create an exit point profile: • from scratch • using an existing or default definition as a template. The main purpose of the exit point profile is to assign an exit point to a message partner for an output session. You can also set the queue threshold for the exit queue. 22.1 Displaying Exit Point Details To display details of an exit point: 1. Start the Application Interface application. 2. Select Exit Points from the View menu. For a description of the fields displayed in the Exit Point window, see "Exit Point Window" on page 302. 22.2 3. Select an exit point from the list. 4. From the Exit Point menu, select Open. Exit Point Window Description The Exit Point window appears after selecting Exit Points from the View menu in the Application Interface application. The window contains a single panel. This panel contains all the Exit Points that have been defined for use on your system. 302 System Management Guide Managing Exit Point Profiles Example of Exit Point window Column descriptions Name The name of the exit point. Assigned to MP Indicates the currently selected message partner. Processing Order Shows the value of the "Processing Order" field. 22.3 Exit Point Details Window Description The Exit Point Details window is displayed when you open an exit point. Example of Exit Point Details window Field descriptions Exit point The name of the exit point. 15 July 2011 303 Alliance Access 7.0.20 Queue threshold The number of messages that may be present in the exit point before an alarm is generated. Assigned to message partner Shows the current message partner assigned to this exit point (if one is assigned) and lists all available message partners. Processing Order The order in which messages are processed. Two values are possible: "FIFO" or "Priority". The default value is "FIFO". 22.4 Defining an Exit Point Introduction You can define an exit point: • from scratch • using an existing one as a template. To define an exit point: 1. If you want to use an existing exit point as a template, then select a suitable exit point from the Exit Point view. To create an exit point from scratch, clear any previous selections you may have made from the Exit Point view using Deselect All from the Edit menu. 2. Do one of the following: • If using an existing exit point as a template, then select New As from the Exit Point menu. The details window for the selected exit point opens. • If creating an exit point from scratch, then select New from the Exit Point menu. An empty Exit Point Profile window opens. 3. Type the name of the new profile in the Exit Point field. 4. Insert a value for the queue threshold by typing in an integer value in the Queue Threshold field. This field determines the number of messages that may be present in the exit point before an alarm is generated. 5. Assign the exit point to a message partner, in the Assigned to message partner field. Select the required message partner from the list. When a message partner is already assigned in this field, selecting another message partner breaks the existing connection and assigns the new message partner. Only one message partner may be assigned to an exit point at any time. Note 304 Associated message partners must be disabled before changing an exit point assignment. 6. Select the order in which messages are processed, in the Processing Order field. Two values exist: "FIFO" or "Priority". 7. Click Add to create the profile in the database. System Management Guide Managing Exit Point Profiles 22.5 Modifying Exit Point Routing Overview After you have defined your new exit point profile, you may want to modify the default routing for the exit point. You must also modify your routing rules to allow any other existing routing points using the routing rules, to route messages to the new exit point. Note By default, a new exit point is used in all defined routing schemas, see "Routing Schemas" on page 314. By default, all exit points are valid routing targets for routing points. Procedure The following steps outline briefly what you have to do: 22.6 1. Sign on in the required mode. If you want to modify the routing rules attached to the "active" routing schema and the default action for a routing point, then you must sign on in housekeeping mode (for more information, see "Starting, Stopping, and Restarting the Servers" on page 71). If you are making a duplicate of the "active" schema and you are making the changes to this, then you can sign on in operational mode. 2. Start the Routing application. 3. If you want to modify the default routing of the new exit point, then select it from the Routing Point view. In the Routing Point details window, modify the default routing (for more information about modifying routing, see "Message Routing" on page 314). 4. Return to the Routing application main window and select the routing point from the Routing Point view that will route messages to the new exit point. 5. In the Routing Point view, select the routing rule(s) that will route the message to the new exit point and modify the rule(s), or add a new rule to the routing point. For more information about modifying a routing rule, see "Routing Rules" on page 318. 6. Repeat this for other routing points which will route messages to the new exit point. 7. Ensure that the routing rules are assigned to the routing schema which is to be "active". 8. Approve and Activate the routing schema. For details, see "Approving and Activating Routing Rules" on page 326. 9. If you are currently running in Housekeeping mode, then switch the system back to Operational mode. Removing an Exit Point Profile Overview You can remove an exit point from the system only if: • the exit point queue is empty • the exit point is not referenced by any existing rule in the current routing schema • the exit point has no message partner attached. 15 July 2011 305 Alliance Access 7.0.20 To remove an exit point: 306 1. Start the Application Interface application. 2. Select the exit point from the Exit Point view in the main window. 3. Open the Exit Point pull-down menu and select Remove. The exit point is removed from the system. System Management Guide Configuring Queues 23 Configuring Queues Introduction This section describes how to configure the Alliance Access queues using the System Management application. For information about the default queues in Alliance Access, see Appendix C, "Queues and Message Processing Functions" on page 394 23.1 Queues and Routing Overview 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. For more information about message routing, see "Message Routing" on page 314. 23.2 Displaying Queues Overview The System Management application displays all queues in Alliance Access in the Queue list pane, and individual queues can be selected to display further information or configure parameters from the Queue Details window. 15 July 2011 307 Alliance Access 7.0.20 To display queues: 1. Run the System Management application. 2. From the View menu, select Queue. The Queue window appears, displaying the list of available queues. Queues are listed by assigned function, whether a queue is an exit point, and current state. You can choose not to display these options by selecting View from the Queue view. If you select Save Current Settings from the File menu, then all your current settings are saved. The next time that you start the System Management application these settings are displayed automatically. The number of queues listed is dependent on whether you are using a high-speed or lowspeed connection. If more than the defined number of queues are present, then there will be more than one list. To navigate between queue lists: • From the Queue menu, select Next or Previous. 23.3 Displaying Queue Details Overview Further information about a queue can be displayed by selecting it from the Queue window. To view detailed information about a queue: 1. Either double-click the queue or select it and select Open from the Queue menu. The Queue Details window opens. When the Queue Details window is open, you can move up and down the list of queues by selecting either Previous or Next from the Queue menu. As you do so, the Queue Details window displays the currently selected queue. 308 System Management Guide Configuring Queues 2. The Queue Details window has two tabs, General Info and Routing Info, that can be selected to see details about a queue. When the Queue Details window opens, the General Info tab is shown. 3. Click the Routing Info tab to display information about the routing rules associated to routing points and about the valid routing targets. For a description of the fields displayed in this window, see "Queue Details Window Routing Info Tab" on page 310. 23.3.1 Queue Details Window - General Info Tab Description The Queue Details window is opened by selecting a Queue in the Queue List window and then selecting Open from the Queue menu (or double-clicking it). The Queue Details window has two tabs, General Info and Routing Info, that can be selected to see details about a queue. For details about the Routing Info tab, see "Queue Details Window - Routing Info Tab" on page 310. Example of Queue Details window - General Info tab Field descriptions Name The name of the queue. Exit Point Indicates whether the queue is an exit point. An exit point is a special routing point linked to a network application (for example, APPLI), which can be assigned to a message partner for delivering messages to banking applications, individuals or various departments in the bank. Function assigned The name of the message processing function (MPF) assigned to the queue. Each MPF performs a specific process on the messages in the queue. Instances in queue The number of message instances in the queue. 15 July 2011 309 Alliance Access 7.0.20 Instances reserved The number of messages in the queue that are being processed by a Message Processing Function (MPF). Queue Threshold The number of messages that can be held in the queue before an alarm is broadcast. Queue State The queue can be held or released. If the queue is held, then messages in it cannot be processed by the associated MPF. 23.3.2 Queue Details Window - Routing Info Tab Description The Queue Details window is opened by selecting a Queue in the Queue List window and then selecting Open from the Queue menu (or double-clicking it). The Queue Details window has two tabs, General Info and Routing Info, that can be selected to see details about a queue. For details about the General Info tab, see "Queue Details Window - General Info Tab" on page 309. Example of Queue Details window - Routing Info tab Field descriptions Rules at this RP - Modify Rules Allowed This parameter determines whether the routing rules associated with this routing point can be modified using the Routing application. For more information about the default settings for routing rule modification, see Appendix B, "Default Settings" on page 389. Rules at this RP - Display Rules Allowed This parameter determines whether the routing rules associated with this routing point are displayed using the Routing application. When a queue is not visible to the Routing application, then queue modification is also denied. For more information about the default queue visibility, see Appendix B, "Default Settings" on page 389. 310 System Management Guide Configuring Queues Valid routing targets Available lists the routing points reachable from this queue. Selected lists the routing points selected for this queue. The maximum number of routing points that can be selected is 99. Note 23.4 All exit points are considered as valid routing targets and are therefore not displayed in the Available/Selected panels. Holding and Releasing Queues To hold or release a queue: 1. From the Queue window, select the queue that you want to hold or release. 2. From the Queue menu, select Hold or Release. Only one of these options is available, depending on the present state of the queue. After a few moments, the state of the queue changes to the selected state. Note 23.5 Only queues which process messages can be held. Queues which create new messages cannot be held (for example, _SI_from_SWIFT, _AI_from_APPLI). Modifying the Queue Threshold To modify the queue threshold: 23.6 1. From the Queue window, select the queue that you want to modify by double-clicking it. The Queue Details window for the selected queue appears. 2. Type a value in the Queue Threshold field. 3. From the Queue menu, select Modify. User-Defined Queues Overview Users can also create their own "routing" queues from the System Management application. The main purpose of "user-defined" queues is to allow additional routing. Depending on their permissions, operators can create, modify, or remove additional 'routing' queues. All operators having permission to modify queues are allowed to modify user-defined queues. A user-defined queue is only visible in the Routing Points window of the Routing application if the Display Rules Allowed flag is set for the queue. User-defined queues are defined as User to distinguish them clearly from System defined queues or Exit queues. User-defined queues can be opened to display their details. If the Modify Rules Allowed flag is set for the queue, then operators can update the target routing point for that queue. The details of the queue can be updated to route messages to a specific queue. 15 July 2011 311 Alliance Access 7.0.20 23.6.1 Create a User-Defined Queue Overview From the System Management application, it is possible to create a user-defined queue. To create a user-defined queue: 1. From the View menu, select Queue. The Queue - System Management window appears. 2. From the Queue menu, select New. The Queue Details - New window appears. 3. Type the queue name in the Name field. Note 4. The name can be up to 20 alphanumeric characters (including underscore characters, but no leading underscore characters). No spaces are allowed in the name. Select Add from the Queue drop-down menu. The new queue is added to the Queue System Management window list. 23.6.2 Remove a User-Defined Queue Overview From the System Management application, it is possible to remove a user-defined queue. Note User-defined queues can only be removed if no instances are in the selected queues and if the queue is not used by any routing rule. If the selected set of queues also contain non-user-defined queues, then the Remove command is not available. To remove a user-defined queue: 312 1. From the View menu, select Queue. The Queue - System Management window appears. 2. Select the queue to be removed. 3. From the Queue drop-down menu select Remove, or press Ctrl + R. The System Management - Removing Queue window appears. 4. Select Yes to remove the queue. System Management Guide Configuring Queues Note 15 July 2011 It is not possible to remove any non-user-defined queues. 313 Alliance Access 7.0.20 24 Message Routing Introduction This section describes how to route messages. 24.1 Message Routing Concept Concept The flow of messages through Alliance Access between routing points is controlled by routing rules. When a message is queued at a routing point, it is processed by the Message Processing Functions (MPF) and a set of routing rules are applied that determine the onward direction of the message. When a message is routed, it flows from routing point to routing point until the processing is completed. There are two types of routing rules in Alliance Access: system and user. The system routing rules specify the routing requirements of applications within Alliance Access, and cannot be changed by the user. The user routing rules are set up and managed by the responsible Alliance Access operator. Each routing point contains at least one routing rule (the default action). The routing rules are applied in sequence and are triggered by: • the processing result of the MPF • keywords. Routing schemas are used to group routing rules for activation within the system. Each routing rule may be a member of several schemas, or belong to none. However, only rules that belong to the "active" schema are used for processing (only one schema can be active at a time). When setting up routing rules, you must first define a routing schema. Keywords must be set up, if user-defined keywords are required, and then linked to a particular Message Syntax Table. Keywords are used to simplify the definition of a trigger condition for routing rules. Routing rules must now be set up, conditional statements defined, and the rules assigned to the routing schema. Note that routing rules must be placed in the order they are to be applied. When all this is complete, the routing schema must be "approved" and then made "active". The tasks associated with message routing are performed using the Routing application. 24.2 Routing Schemas Introduction This section describes how to use routing schemas. 314 System Management Guide Message Routing 24.2.1 Routing Schema Concept Concept Routing schemas are used to group routing rules to allow activation within the system. Each routing rule can belong to one or more routing schemas. However, only routing rules assigned to the active schema are used for processing messages that arrive at a routing point. The Routing application allows you to: • create a routing schema • duplicate an existing routing schema to modify "active" routing rules, without having to restart the servers in housekeeping mode. 24.2.2 Create or Modify a Routing Schema Overview Use the following procedure to modify or create a routing schema. By "duplicating" an existing routing schema, you can modify "active" routing rules without having to restart the servers in Housekeeping mode. To create or modify a routing schema: 1. Run the Routing application. 2. From the View menu, select Routing Schema. The Routing Schemas window appears, displaying the list of defined routing schemas. 3. Click the active routing schema that you want to modify, for example, A. 4. From the Routing Schema menu, select Duplicate. The Routing Schema Duplicate window appears. In the Name field, type a character with a value of A to Z, for example, B. 5. 15 July 2011 In the Description field, type a description of the routing schema. 315 Alliance Access 7.0.20 6. In the Routing Schema menu, select Add. All rules that are used by the source schema (for example, A) are now added to the duplicate schema (for example, B). 7. From the View menu, select Routing Point, and open the routing point for which you want to modify the routing. 8. From the Routing Rule panel, click the routing rule that you want to modify. 9. From the Routing Rule menu, select Save As. 10. Change the proposed sequence number to a number just preceding the sequence number of the rule that you have just copied (for example, if it was rule number 100, give it a sequence number of 99). 11. In the Description field, type a description of the routing rule. In the Used in Routing Schema(s) list pane, only the duplicate schema (for example, B) should be displayed in the Selected list pane. 12. Click Add. 13. From the Routing Rule panel, open the original routing rule that you have just copied (for example, 100). 14. In the Used in Routing Schema(s) panel, move the duplicate schema (for example, B) from the Selected list pane to the Available list pane. 15. Click Modify. 16. Modify the rules only assigned to Schema B to your needs. 17. From the Routing Rule menu, select Validate. 18. Approve and activate the duplicate routing schema (for example, B). For more information, see "Approving and Activating a Routing Schema" on page 316. For more information about creating and assigning the routing rules associated with a routing schema, see "Routing Rules" on page 318. 24.2.3 Approving and Activating a Routing Schema Overview Once the routing rules have been assigned, the routing schema must be approved and then activated. Only routing rules in the "active" routing schema are used to route messages in Alliance Access. To approve and activate a routing schema: 316 1. Select the required routing schema from the Routing Schemas window. 2. From the Routing Schema menu, select Approve to change the status of an "unapproved" routing schema to "approved". 3. From the Routing Schema menu, select Activate to make the routing schema active. System Management Guide Message Routing 24.3 Routing Keywords Introduction This section describes how to use routing keywords. 24.3.1 Routing Keyword Concept Concept Routing keywords, created using the Routing application can be used: • to assign routing keywords to message types using the SWIFT Support application • when creating a conditional routing statement using the Criteria Definition window. 24.3.2 Defining Routing Keywords Overview Routing keywords are dependent on the Message Syntax Table. Each time a new version of the message syntax table is released, users must re-define their routing keywords according to the new version, to map the routing keywords included in the routing rules. For a detailed description of the pre-defined routing keywords, see "List of Message Keywords" on page 331. To define routing keywords: 15 July 2011 1. Run the Routing application. 2. From the View menu, select Routing Keyword. The Routing Keywords window appears, displaying the list of user-defined routing keywords. 3. From the Routing Keyword menu, select New. The Routing Keyword New window appears. 4. In the Name field, type a name for the keyword. 317 Alliance Access 7.0.20 5. In the Description field, type a free text description of the keyword. For example, you can describe how the keyword will be used. 6. In the Type menu list, select one of the following: • String, which represents any character (ASCII set including CrLf) • Date, of the format DD/MM/YYYY • Amount, of the format <16 digits>, <6 digits> • Integer, which represents any number (without ","). 7. Click Add . After defining a new routing keyword, the Keyword must be assigned to a Message Syntax Table, a Message Type, a Message Field, or even Message sub-field. 24.3.3 Assigning Routing Keywords to a Message Syntax Table Overview The routing keywords, defined using the Routing application, must be assigned to a specific Message Syntax Table and can also be assigned to fields in specified message types. The SWIFT Support application is used to assign routing keywords. For more information, see "Assigning Routing Keywords" on page 65. 24.4 Routing Rules Introduction This section describes how to use routing rules. 24.4.1 Routing Rule Concept Concept Routing rules are assigned to routing points, and can also be associated with routing schemas. Only the routing rules associated with the "active" routing schema are active in Alliance Access. Routing points also have a default routing rule (default action). Each routing rule is made up of two parts: • "Trigger" conditions that determine whether the rule actions are to be applied to a message instance • Actions to be carried out on the message instance if the trigger conditions are met. 318 System Management Guide Message Routing Note To modify rules, add rules, or delete existing rules of the active routing schema, the Alliance Access servers must be restarted in Housekeeping mode. Once a change is made to the routing rules and assigned to a particular schema, the schema is deactivated. You must reactivate it before the servers can be restarted in Operational mode. For more information about activating a schema, see "Approving and Activating a Routing Schema" on page 316. To change a schema that is already "active" without switching to Housekeeping mode, you must duplicate the schema and make changes to the duplicate. This allows you to modify routing rules in Operational mode. To apply the changes you have made to the routing rules, the duplicate schema must be made active. 24.4.2 Defining Routing Rules To define a routing rule: 1. Sign on in the required mode. If you are modifying any routing rules attached to the "active" routing schema, then sign on in Housekeeping mode. If you are making a duplicate of the "active" schema and making the changes to this, then you can sign on in Operational mode. 2. Run the Routing application. The Routing Points window appears, displaying the list of available routing points. Note Only queues that can be viewed and modified by the Routing application appear in this window. For more information, see "Configuring Queues" on page 307. These options can be set in the System Management application. 3. 15 July 2011 From the main Routing Points window, double-click a queue, or click a queue to select it, and from the Routing Point menu, select Open. Note that a new menu called Routing Rule is added to the menu bar when you open a queue. The details of the selected routing point appear. 319 Alliance Access 7.0.20 4. From the Routing Rule menu, select New to create a routing rule. Alternatively, select a rule from the Routing Rule list pane, and from the Routing Rule menu select Open or New As, to change an existing rule. The Routing Rule Details window appears. 5. Make modifications to the Description, Condition, and Action tabs, as required. For more information about the Description tab, see "Description Tab" on page 320. For more information about the Condition tab, see "Condition Tab" on page 321. For more information about the Action tab, see "Action Tab" on page 323. 6. Any rules that have message criteria must be validated to ensure that the entry on the Message On field is valid. To do this, select Validate from the Routing Rule menu. 7. Click Modify to update the rule, or Add to create a rule. 24.4.3 Description Tab Description The Description tab appears in the Routing Rule Details window which appears by selecting a routing rule in the Routing Point Details window. 320 System Management Guide Message Routing Example Field descriptions Routing point The name of the routing point where the displayed rule is active. Sequence number The "order of activation" of the displayed rule in the set of rules for this routing point. Use this field to specify the sequence number of the rule in the routing table. By default, the first routing rule is given the number 100 and each subsequent rule added is given a number incremented by 100. Description A brief description of the rule. Used in Schema(s) Assigns this routing rule to the selected routing schemas. The Available list contains a list of all the routing schemas in Alliance Access. Selecting one or more schemas from this list pane and clicking the appropriate Transfer button switches the selected schemas to the Selected list. The routing rule is now assigned to all schemas in the selected list. 24.4.4 Condition Tab Description The Condition tab appears in the Routing Rule Details window which appears by selecting a routing rule in the Routing Point Details window. 15 July 2011 321 Alliance Access 7.0.20 Example of Condition tab Field descriptions Condition on Select from the following: • Always: allows you to define an action that is always performed if none of the previous routing rules have been positively evaluated and original completed. The Function Result and the Message panels are not available. • Function Result: opens a transfer list pane. For more information, see "Function Result" on page 322. • Message: opens a text input field where conditional statements referring to specific message attributes can be built. For more information, see "Message" on page 323. • Function Result and Message: opens the Function Result transfer list pane and Message text input field. For more information, see "Function Result" on page 322 and "Message" on page 323. Function Result The routing result that the assigned MPF can return for a message instance. The Available list contains a list of all processing results the MPF can return. Selecting a result from this list pane and clicking on the appropriate transfer button switches the result to the Selected list. The selected result now becomes a trigger condition for the rule. You may select more than one processing result from the Available list pane. The routing action is performed if one of the processing results specified in the trigger condition matches the processing result returned by the MPF. A function result of Success means that the transmission was successful (not authentication). 322 System Management Guide Message Routing Message This field is used to build one or more conditional statements. A conditional statement is a rule criterion based upon a list of approved message attributes called keywords. Each conditional statement constructed in this field must follow a predefined syntax which uses keywords and Boolean operators. Help on creating a conditional statement using this syntax is available by using the Assist command. For more information about building a conditional statement, see "Using the Criteria Definition Window" on page 328. 24.4.5 Action Tab Description The Action tab appears in the Routing Rule Details window which appears by selecting a routing rule in the Routing Point Details window. Example of Action tab Field descriptions Action on To specify what actions are triggered when conditional criteria are satisfied. An action is directed towards the source instance or a new instance or both. The Action on option button is used to select the type of message instance which will be the target of the rule action. The possible values are: • New Instance: opens the New Instance sub-panel • Source Instance: opens the Source Instance sub-panel • Source and New Instance: opens the New Instance and Source Instance sub-panels. 15 July 2011 323 Alliance Access 7.0.20 Source Instance This sub-panel is used to specify the target routing point of the source. It also allows you to define the type of intervention that you want to append to the instance, and to change the unit assignment of the instance. Action Specifies the action to be taken on the source instance. If an action is taken on the source instance then no further rules are tried. The options are: • To Addressee, routes a message instance to a message receiver, selecting its preferred network according to the receiver's definition in the Correspondent Information File. • Complete, the life cycle of the message is finished. No further processing is required. • Route to, specifies the target routing point of the source instance. Select a routing point from the list of valid targets. • None, no action is performed on the instance. Append intervention You may select from: • No Intervention, no intervention is appended to the instance • Copy Text Intervention, a copy of the message text is included as an intervention • Free Formatted Intervention, selecting this option opens a text input data field where you can input the text of the intervention. Unit Select from: • Assign To, to assign one of the approved units to an instance • Keep current, if you do not want to change the current unit assignment. Routing code The routing code that the Routing application adds to a message instance, when the routing rule is applied. This code is transmitted to a back-office application (that is, a message partner) for routing purposes within that application. If the message is to be sent to the back office using the CAS protocol, then the length of the routing code must be no more than six characters. Priority Select: • Keep current, if you do not want to change the current Instance Priority value • a new value for the Instance Priority. The possible values are: 1 (Highest), 2, 3 (System), 4, 5 (Urgent), 6, 7 (Normal), 8, 9 (Lowest). New Instance This sub-panel is used to create and specify the destination and intervention text for new instance (notifications and copy instances). 324 System Management Guide Message Routing Type Select from: • Copy: a copy instance must always be routed to another routing point, or to an addressee • Notification: a notification must also be routed to another routing point or to an addressee It is usually addressed to the sender of the message, and can be used to specify the following details about the original or copy instance: – Transmission, to indicate that the instance has been sent over a network – Information, to give more information about a particular action – History, to specify intervention details, such as transmission, system and user interventions. Action The action to be taken on the new instance and the options are: • To Addressee, routes a message instance to a message sender or a message receiver • Route to, specifies the target routing point of the instance. Select a routing point from the list of valid targets. Append intervention You may select from: • No Intervention, no intervention is appended to the instance • Copy Text Intervention, a copy of the message text is included as an intervention • Free Formatted Intervention, selecting this option opens a text input data field where you can input the text of the intervention. Unit Select from: • Assign To, to assign one of the approved units to the new instance • Do not assign any, to remove any existing unit assignment • Keep current: use this option if you do not want to change the current unit assignment. Note Notifications always inherit the unit assignment of their original or copy instance and this cannot be changed, therefore only Keep current can be selected. Routing code The routing code that the Routing application adds to a message instance, when the routing rule is applied. This code is transmitted to a back-office application (that is, a message partner) for routing purposes within that application. If the message is to be sent to the back office using the CAS protocol, then the length of the routing code must be no more than six characters. 15 July 2011 325 Alliance Access 7.0.20 Priority Select: • Keep current, if you do not want to change the current Instance Priority value • a new value for the Instance Priority. The possible values are: 1 (Highest), 2, 3 (System), 4, 5 (Urgent), 6, 7 (Normal), 8, 9 (Lowest). 24.4.6 Approving and Activating Routing Rules Overview After the routing rules have been created or modified, they must be "approved" and "activated". This is achieved using the routing schemas. As the routing rules are added or modified, they must be assigned to a routing schema using the Used in Routing Schema pane of the Description tab. All the routing rules assigned to a routing schema can then be "approved" and "activated" when the routing schema is "approved" and "activated". For more information, see "Approving and Activating a Routing Schema" on page 316. Note An active schema must exist to start the servers in Operational mode. 24.4.7 Routing Rule Order Overview By default, the first routing rule added is given the number 100, and each subsequent rule added is given a number incremented by 100. For example, if there are three routing rules already created, then these will have the numbers 100, 200 and 300. When you manually create a routing rule, this is given the number 400. The routing rules are applied to the message instances in order of their sequence numbers, from lowest to highest. If you have to activate the routing rules in a different order, then you must duplicate the routing rules in the order required (each can be given a new sequence number), and then delete the originals. The default routing rule is only applied if no routing rules are assigned to the routing point, or none of the assigned rules are applicable. When designing new rules, consider all the processing that must be performed at the selected routing point. If an action is performed too early, then it can prevent important processing from occurring later. For example, if the first rule in the sequence is "complete the instance", then none of the other rules in the list are applied. You can also leave gaps in the rule sequence numbering so that other rules can be inserted in the correct order at a later date. For example, instead of numbering the rules 101, 102, 103, and so on, number them with gaps of 100, that is 100, 200, 300, and so on. 326 System Management Guide Message Routing 24.4.8 Routing Rules for User-Defined Queues Overview Depending on their individual permissions operators can create or modify routing rules for userdefined queues from within the Routing application. By default, no routing rules exist when a user-defined queue is created. The routing rules can be created in the same way as for any other queue. User-defined queues are displayed in the list of valid routing targets on the Routing Points - Routing window. There is no message processing function for a user-defined queue. Therefore, a condition for a routing rule cannot be based on a function result. Note When a new routing rule is added to a user-defined queue, the Condition On field (within the Condition tab) defaults to Always. However, if the Function option is selected, then the Function Result Available and Selected boxes are displayed without a routing result. 24.4.9 Adding and Modifying Routing Rules for User-Defined Queues To add or modify routing rules for user-defined queues: 1. Run the System Management application. 2. From the View list menu, select Queue. The Queue-System Management window appears. 3. From the Queue list menu, double-click the user-defined queue. The Queue Details window appears. 4. Select the Routing Info tab and select the Modify Rules Allowed and Display Rules Allowed check boxes. 5. Select the Valid routing target from Available to Selected. 6. From the Queue list menu, select Modify. 7. Close the Queue Details window and the Queue - System Management window. 8. Run the Routing application. The Routing Points - Routing window appears. 9. Select the relevant user-defined queue from the list displayed. 10. From the Routing Point list menu, select Open, or press Ctrl + O to display the relevant user-defined queue's routing details. 24.4.10 Removing User-Defined Queues To remove a user-defined queue: 15 July 2011 1. Run the System Management application. 2. From the View list menu, select Queue. The Queue - System Management window appears. 3. Select the relevant user-defined queue to be removed. 327 Alliance Access 7.0.20 24.5 4. From the Queue list menu, select Remove, or press Ctrl + R. The System Management Removing Queue window appears. 5. Select Yes, to remove the user-defined queue. Using the Criteria Definition Window Overview The Criteria Definition window is available from the Routing Rule Details window to help you create conditional statements when the Condition on field is set to Message or Function Result and Message. The elements used to build a conditional statement are: • Keywords • Operators • Boolean expressions • Values, which vary depending on which keyword is selected. For example, if the keyword is amount, the value must be numeric; if the keyword is currency code, the value must be a currency code in the standard 3-character ISO format, and so on. • The attributes of a message instance, listed as keywords. These keywords can be selected and used with other operators and expressions to form a conditional statement. To see the criteria definition window: • From the Condition tab of the Routing Rule Details window, click Assist or select Assist from the Routing Rule menu. The Criteria Definition window appears. For a description of the fields displayed in this window, see "Routing - Criteria Definition Window" on page 328. 24.6 Routing - Criteria Definition Window Description From the Condition tab of the Routing Rule Details window, click Assist or select Assist from the Routing Rule menu. The Criteria Definition window appears. 328 System Management Guide Message Routing Example of Routing - Criteria Definition window Field descriptions Keyword A list of all approved message keywords that can be used to form a conditional statement. This list contains all pre-defined keywords (see "List of Message Keywords" on page 331), and the keywords that you have customised (see "Routing Keywords" on page 317). To display a description for the keyword in the Keyword Description field, click a keyword in the list. To select a keyword to use in a conditional statement, double-click the keyword. Depending upon the keyword selected from the list, either a special input data field or a list pane appears in the top right corner of the window. In the case of a text input field, the type of input expected appears as a label above the field. In the case of a list pane, it shows each of the values that may be assigned to the keyword. For more information about the meaning of each keyword, see "List of Message Keywords" on page 331. Available Values Appears after selecting a keyword. It displays each of the values that may be assigned to the selected keyword. You can only make an assignment after selecting a relational operator from the Operator buttons. Operator All relational and arithmetic operators that may be used within a conditional statement. Each operator appears as a button. Clicking on any operator button inserts the operator at the cursor position in the Criteria field. The available relational operators are: • < Term to the left of the operator is less than the term to the right. • != Terms either side of the expression are not equal. • > 15 July 2011 329 Alliance Access 7.0.20 Term to the left of the operator is greater than the term to the right. • <= Term to the left of the operator is less than or equal to the term to the right. • = Terms either side of the expression are equal. • >= Term to the left of the operator is greater than or equal to the term on the right. • like This operator is used to find a match between one character string and another. Permitted wildcards are: – "%" substitutes 0 or more characters. – "_" substitutes one character only. For example, the statement (Sender like SMBKBEBB%) checks the Sender field of each routed message for a string matching the BIC-12 address SMBKBEBB%. The following arithmetic operators are also available. However, they can only be entered into the editing window of the Routing Rule Details window: • + Add terms either side of the operator. • Subtract term to the right of the operator from the term on the left. • / Divide the term on the left of the operator by the term on the right. • * Multiply the term on the left of the operator by the term on the right. String Value The special characters that can be used within a conditional statement are: • \n New line • \r Carriage return • \t Tab • \' Single quote • \\ Single backslash 330 System Management Guide Message Routing Expression The expressions that can be used within a conditional statement are: • and Logical "and" function. • or Logical "or" function. • not Does not equal. • ( Establish precedence open parenthesis. • ) Establish precedence close parenthesis. Undo Removes the last entry that was inserted in the Criteria field. Clear Clears all existing entries that appear in the Criteria field. 24.7 List of Message Keywords Overview This section contains a list of all default message keywords that can be used to form a conditional statement when creating a routing rule. Warning Do not use the keywords, Date, Time, Amount, or Today, in a conditional statement. These keywords are reserved for use by the system only. Addressee_information This keyword represents the Server-to-Receiver instructions and allows Alliance Access to route on field 115 of block 3. The content and the usage of this field depend on the FINCopy service provider. Addressee_integrated_appl This keyword represents the name of the network that receives the instance. For example, SWIFT or APPLI. Warning Do not use this keyword in the routing conditions of the _AI_from_APPLI queue. Amount This keyword represents the amount of currency. The format for representing the amount is: 16 positions to the left of the decimal point (without the thousand separators) and 6 positions to the right of the decimal point: 15 July 2011 331 Alliance Access 7.0.20 <16 digits>,<6 digits> For example, 100000,000 Alliance Access may extract the value of Amount from the following fields of the message text: 32A:, 32B:, 32P:, 32R:, 32K:, 34A:, 34B:, or 19. Warning Do not use the Amount keyword in a conditional statement. It is reserved for use by the system only. Note When you enter an amount, Alliance Access does not validate the value that you enter. Authentication When Alliance Access receives a message, it authenticates the message. This keyword represents the result of the authentication and it applies to incoming messages only. The values are: • Auth_Failure • Bypassed • Invalid_CertID • Invalid_Digest • Invalid_SignDN • Not_Needed • Sig_Failure • Success This keyword can be used for routing FileAct messages. Authorisation_result When Alliance Access receives a message, it checks that the message is authorised (if authorisation is required for that message). This keyword represents the result of the authentication and it applies to incoming messages only. The values are: • Autho_NotInValidPeriod • Authorisation_Bypassed • Authorisation_Failure • Authorisation_NotEnabled • Authorisation_NotNeeded • Authorisation_Success • No_Authorisation • Not_authorised 332 System Management Guide Message Routing This keyword can be used for routing FileAct messages. Authorising_operator_name This keyword represents the username of the operator that authorised the instance. This keyword can be used for routing FileAct messages. Banking_priority This routing keyword allows Alliance Access to route a message on field 113 in block 3. Business_area This keyword represents the business area code of an MX or FileAct message. Checksum This keyword represents the result of the checksum algorithm for a message that Alliance Access receives. This keyword applies to incoming messages only. The value is: Chck_Failure. Class This keyword represents the class of the message. The values are: • Broadcast • Message • Template This keyword can be used for routing FileAct messages. Copy_recipient_DN This keyword represents the recipient DN of the SWIFTNet Copy message or file. This keyword can be used for routing FileAct messages. Copy_state This keyword represents the state of the SWIFTNet Copy service. The values are: • Active • Bypass • TCopyFallback Copy_type This keyword represents the type of the SWIFTNet Copy. The values are: • Full • Header (only for FileAct) 15 July 2011 333 Alliance Access 7.0.20 This keyword can be used for routing FileAct messages. Creating_application This keyword represents the application that created the message instance. This keyword can be used for routing FileAct messages. Creating_mpfn This keyword represents the message processing function that created the message instance. This keyword can be used for routing FileAct messages. Creating_operator_name This keyword represents username of the operator that created the message. This keyword can be used for routing FileAct messages. Creation_date This keyword represents the date on which the message instance was created. The format is DD/MM/YYYY. For example, 22/02/2011. This format is specific to the Routing application and has no relationship with the date format used in the System Management application (SMA). This keyword can be used for routing FileAct messages. Creation_queue This keyword represents the name of the queue where the message or message instance was created. This keyword can be used for routing FileAct messages. Creation_time This keyword represents the time the message was created. The format is HH:MM:SS. For example, 08:15:30. This format is specific to the Routing application and has no relationship with the time format used in the System Management application (SMA). This keyword can be used for routing FileAct messages. Currency This keyword represents the currency that is specified in the message. The ISO currency format is used, for example, USD, GBP, EUR. Note Alliance Access may extract the Currency value from the following fields of the message text: 32A:,32B:, 32P:, 32R:, 32K:, 33A:, 33K:, 34A:, 34B: and F68A Delivery_requested This keyword indicates whether a delivery notification was requested. The value of the keyword is either true or false. This keyword can be used for routing FileAct messages. 334 System Management Guide Message Routing Disposition_address_code This keyword represents a disposition address code and allows Alliance Access to route messages based on the content of the routing code. If the configuration parameter RTV Routing is set to ON, then this keyword automatically takes the value RTV for retrieved messages. Duplicate This keyword indicates whether the message is a possible duplicate. This applies to incoming messages only. The values are: • PDE: Possible Duplicate Emission. The correspondent adds this trailer to the message. • PDR: Possible Duplicate Reception. SWIFT adds a Possible Duplicate Message trailer to a message when SWIFT believes that a message delivery has failed. When Alliance Access receives the message, it converts a Possible Duplicate Message to a Possible Duplicate Reception • PDE_and_PDR: Possible duplicate (a combination of PDE/PDR). This keyword can be used for routing FileAct messages. File_logical_name This keyword represents the logical name of the file. This keyword can be used for routing FileAct messages. File_size This keyword represents the size of the file in bytes. This keyword can be used for routing FileAct messages. FIN_user_header This keyword represents the complete FIN User Header (block 3) of an MT message. You can use this keyword to route messages that are validated through the Sanctions service. For example, you can configure a routing rule that routes the messages which Sanctions Screening over SWIFT reports as true hits. In this case, the condition must check whether the value of the field 433 contains a true hit, as follows, "%{433:/NOK/%". Format This keyword represents the format of the message, for example, Swift. This keyword can be used for routing FileAct messages. Full_text This keyword represents the Message Text (Block 4 for SWIFT format) of a message. This allows Alliance Access to route a message based on the content and the values in a message. Warning 15 July 2011 Using this keyword dramatically reduces the overall performance of Alliance Access. 335 Alliance Access 7.0.20 Instance_type This keyword represents the type of message instance. The values are: • Copy • Notification • Original This keyword can be used for routing FileAct messages. Last_operator_name This keyword represents the username of the operator that last worked with the instance. This keyword can be used for routing FileAct messages. Live_mesg This keyword represents the distinction between "live" or "test" messages. The value of the keyword is either true or false. This keyword can be used for routing FileAct messages. Mesg_type This keyword represents the FIN or System message type. Format is nnn. Note No prefix is required, only the message type number must be entered. For example, for an MT 103, enter 103, or for a QUIT message (APDU 05), enter 05. This keyword can be used for routing FileAct messages. Message Identifier This keyword represents the message identifier. This keyword can be used for routing FileAct messages. Modifying_operator_name This keyword represents the username of the last operator that modified the message text. MUR This keyword represents the Message User Reference. MX_keyword_1 This keyword represents the first keyword for an MX message. MX_keyword_2 This keyword represents the second keyword for an MX message. MX_keyword_3 This keyword represents the third keyword for an MX message. 336 System Management Guide Message Routing NAK_reason This keyword represents a NAK reason code, which explains why the message was not acknowledged. Alliance Access can perform additional routing based on this keyword, which is applicable to messages sent over the SWIFT network. Nature This keyword represents the nature of the message. The values are: • Finance: MT 101 to MT 998, MX messages, and FileAct messages • Network: All System MTs (except MT 05) • Secure • Service: MT 05 (QUIT) • Text: MT 999 messages Network_application This keyword represents the SWIFT application that handles the message, for example, FIN, APC, LTC. This keyword can be used for routing FileAct messages. Network_delivery_status This keyword represents delivery status of the message to the network. The values are: • Network_Aborted • Network_Acked • Network_N_A • Network_Nacked • Network_RejectedLocally • Network_TimedOut • Network_WaitingAck This keyword can be used for routing FileAct messages. Network_priority This keyword represents the priority of the message over the network. The values are: • System • Urgent • Normal This keyword can be used for routing FileAct messages. 15 July 2011 337 Alliance Access 7.0.20 Non_delivery_requested This keyword indicates whether a Non-Delivery Warning was requested. The value of the keyword is either true or false. Pac This keyword represents the result of the secondary authentication that Alliance Access performs on a message that it receives. This keyword applies to incoming messages only. The values are: • Auth_Failure • Bypassed • Invalid_CertID • Invalid_Digest • Invalid_SignDN • Not_Needed • Sig_Failure • Success Partial This keyword indicates whether the message is a partial message. The value of the keyword is either true or false. Possible_duplicate This keyword indicates whether the message is possibly a duplicate of another message. This keyword can be used for routing FileAct messages. Priority This keyword represents the priority of the message instance within Alliance Access. The values are 9 (lowest priority) through 0 (highest priority). This keyword can be used for routing FileAct messages. Receiver This keyword represents the full 11-character BIC address (Institution Identifier) of the receiver of the message. If the message was input to SWIFTNet (Sub-format I), then the receiver is the correspondent to whom the message is being sent. The field contains the correspondent's address. If the message was output from the SWIFTNet (Sub-format O), then you are the receiver of the message, which was sent by your correspondent to one of your own destinations. This keyword can be used for routing FileAct messages. Related_TRN This keyword represents the related Transaction Reference Number. For SWIFT messages, this is located in field 21 of the message text. 338 System Management Guide Message Routing Requestor_DN This keyword represents the Requestor DN of an MX or FileAct message. Responder_DN This keyword represents the Responder DN of an MX or a FileAct message. Routing_code This keyword represents free-format text to influence routing. The field can be manually filled for a message in the Reception Modification Queue. When the configuration parameter RTV Routing is set to OFF, the routing code is automatically set to RTV for a retrieved message. The routing code has a maximum length of six characters. The field is visible in the Message Instance Details in the Message File application. This keyword can be used for routing FileAct messages. RT_SNL_endpoint This keyword represents the real-time SWIFTNet Link endpoint. It applies to incoming MX or FileAct messages only. Sender This keyword represents the 11-character BIC address (Institution Identifier) of the sender of the message. If the message was input to the network (Sub-format = "I"), then you are the sender of the message and your own address appears in the field. If the message was output from the network (Sub-format = "O"), then the sender is the correspondent who sent you the message and the sender address appears in the field. This keyword can be used for routing FileAct messages. Sender_reference This keyword represents the message reference for messages that are entered by APPLI. This keyword can be used for routing FileAct messages. Service_name This keyword represents the SWIFTNet Service to which an MX or FileAct message belongs. SnF_queue This keyword represents the name of the store-and-forward queue. This keyword applies to incoming MX or FileAct messages only. Src_entity This keyword represents the name of the entity through which Alliance Access received a message from a message partner. Entity Value APPLI network name of message partner profile SWIFT network BIC9 + "XXX" + F (in) or A (apc) This keyword can be used for routing FileAct messages. 15 July 2011 339 Alliance Access 7.0.20 Status The keyword indicates whether the message is live or completed. This keyword can be used for routing FileAct messages. Sub_format This keyword indicates whether the message was input or output to SWIFTNet after it was created. The values are: • Input • Output This keyword can be used for routing FileAct messages. SWIFT_copy_service This keyword represents the SWIFT copy service identifier (3 characters in length). SWIFT_receiver_address This keyword represents the SWIFT address of the receiver (12 characters in length). SWIFT_sender_address This keyword represents the SWIFT address of the sender (12 characters in length). Note If the Routing application must check a sender with logical terminal X, then it must check the Sender instead of the SWIFT_sender_address. Time This keyword represents the time of routing. The format is: HH:MM:SS. For example, 08:15:45. This format is specific to the Routing application and has no relationship with the time format specified by the Display Format parameter in the System Management application. Warning Do not use the Time keyword in a conditional statement. It is reserved for use by the system only. This keyword can be used for routing FileAct messages. Today This keyword represents the date of routing. The format is: DD/MM/YYYY. For example, 20/01/2011. This format is specific to the Routing application and has no relationship with the date format specified by the Display Format parameter in the System Management application. Warning Do not use the Today keyword in a conditional statement. It is reserved for use by the system only. This keyword can be used for routing FileAct messages. 340 System Management Guide Message Routing TRN This keyword represents the Transaction Reference Number. For SWIFT messages, this is located in field 20 of the message text. UMID This keyword represents the Unique Message Identifier. This keyword can be used for routing FileAct messages. Unit_name This keyword represents the name of the unit that owns the message instance. This keyword can be used for routing FileAct messages. Validation This keyword represents the validation level that the message passed successfully. The values are: • Intermediate • Maximum • Minimum This keyword can be used for routing FileAct messages. Validation_flag This keyword represents the Message User Group. This routing keyword allows Alliance Access to route a message on field 119 in block 3. For example, it allows Alliance Access to route MT 103, MT 103.STP and MT 103.REMIT in different ways. In this case, the condition on a message can be set to: ((Msg_type = '103') and (Validation_flag = 'STP')) Note STP must be entered capital letters for the routing rule to be applied. This keyword can be used for routing FileAct messages. Value_date This keyword represents the date (as a string) on which funds are at the disposal of the receiver. Note Alliance Access may extract the Value_date from fields 32A: or 32B: of the message text. Value_date2 This keyword represents a date on which funds are at the disposal of the receiver. The format is: DD/MM/YYYY. This keyword can be used with the variables "yesterday", "today", or "tomorrow" to route messages based on whether the value date in the message is less than, equal to or greater than the date of yesterday, today, or tomorrow. 15 July 2011 341 Alliance Access 7.0.20 This format is specific to the Routing application and has no relationship with the date format specified by the Display Format parameter in the System Management application. Note Alliance Access may extract the Value_date2 from fields 32A: or 32B: of the message text. Verifying_operator_name This keyword represents the username of the last operator that verified the message. 24.8 Creating Simple Conditional Statements Overview This section describes how to: • create a simple conditional statement • set precedence in a statement. 24.8.1 Creating a Simple Conditional Statement Overview In the following example, a conditional statement is created based on the currency and message authentication attributes of a typical source message. To create a simple conditional statement: 1. In the main Routing Point window, double-click the routing point to which you want to assign a conditional statement. 2. Select New or New As from the Routing Rule menu. 3. Click the Condition tab. 4. Select Message from the Condition on list. 5. Click Assist. 6. From the Keyword list, click Currency. Tip Use Clear to remove the existing entries and activate the Keyword list pane, or Undo to remove the last entry. 7. Click 8. In the String value field, type GBP, then click anywhere in the Criteria field. = . This part of the expression appears in the Criteria field with quotes automatically inserted (for example, Currency='GBP'). 9. Click and . 10. In the Keyword list pane, click the keyword Authentication. A new list pane Enum Values appears. 342 System Management Guide Message Routing 11. Click = . 12. In the Enum Values list pane, select Success. The conditional statement is now complete in the Criteria field: (Currency = 'GBP') and (Authentication = Success) 13. Click OK . The condition is copied to the Message field in the Routing Rule Details window. 24.8.2 Setting Precedence in a Statement Overview By the careful use of parenthesis you can define the precedence in a statement. For instance in the following example: A OR (B AND C) will be interpreted by checking first if B AND C is true, after which the result is used in the A OR part. Changing the location of the parenthesis changes the result entirely, by "forcing" precedence so that A OR B is processed first: (A OR B) AND C This gives different results as A OR B is checked first, after which result AND C is checked. The following example is a little more complex. (Mesg_type = '530') OR (Mesg_type = '532') OR (Mesg_type = '599') AND (Sender = 'IRVTBEBEXXX') OR (Sender = 'PARBBEBZXXX') Here the parenthesis individually force each value assignment to be verified TRUE or FALSE before the OR and AND operators are processed into a result. Can you see the difference between this example and the one below: ((Mesg_type = '530') OR (Mesg_type = '532') OR (Mesg_type = '599')) AND ((Sender = 'IRVTBEBEXXX') OR (Sender = 'PARBBEBZXXX')) Yes, the double parenthesis - parenthesis can also be nested. In the case of nested parenthesis, the innermost set of parenthesis have precedence. In this example, each '=' assignment in parenthesis is verified to be TRUE or FALSE. The outer set of parenthesis are then evaluated either side of the AND operator. Finally, the two results are then subjected to the AND. 15 July 2011 343 Alliance Access 7.0.20 25 Configuring Message Delivery (Delivery Subsets) Introduction This section describes how you can use the SWIFT Interface application to control the order in which you receive output messages from the SWIFT network. Users can control the order in which they receive output messages from the SWIFT network. A receiving user can define delivery subsets specifying how messages are to be delivered to that destination. The messages addressed to that destination are then queued by the system in the defined delivery subsets. The delivery criteria that can be specified include message priority, message category, message type, branch code, and the presence of field 13C. Users may also choose to receive certain queued messages in value date order. In the absence of user-defined delivery subsets, messages are queued in three subsets: • System • Urgent • Normal. Alliance Access provides you with the possibility of specifying User-defined Delivery Subsets for a destination using the SWIFT Interface application. 25.1 Requesting a Report of Current Delivery Subsets Overview Before making any changes to the Delivery Subsets, it is recommended to send a Delivery Instructions Request (MT 035) to FIN. A Delivery Instructions Report (MT 055) is sent in response, listing the delivery subsets currently held for the destination, and is sent to the requesting logical terminal. It also indicates whether value date ordering is active for that destination. The MT 035 is generated using the Message Creation application. For information about how to create and send system messages, see "Preparing Messages: An Overview" and "Creating Messages" in the Daily Operations Guide. 25.2 Defining a Future Delivery Subset Overview To change delivery subsets an MT 047 (Redefine Delivery Subset), containing the details of the change, must be sent to SWIFT. Before attempting to redefine a delivery subset, users must know that Alliance Access does not validate the content of an individual subset, and it does not ensure that all subset definitions for a destination are complete. If the definitions are incorrect then SWIFT replies with an MT 015 Delayed NAK. If the MT 047 is valid, then the corresponding subset change is made in FIN at midnight local time, and you are informed by an MT 067 (Delivery Instructions Redefinition Report) to indicate that the change was made successfully. 344 System Management Guide Configuring Message Delivery (Delivery Subsets) To define a future delivery subset: 1. Run the SWIFT Interface application. 2. From the View menu, select Destination. The Destination main window appears. 3. From the Destination main window, double-click the Destination for which you want to define a future delivery subset. The Destination Details window appears. 4. Click the Future Subsets tab. For a description of the fields displayed in this tab, see "Future Subsets Tab" on page 348. 5. If you require date ordering, then select the Value Date Ordering check box. 6. If you wish to share the subset, then select Share with Overflow or Share with Load Balancing from the Subset Sharing field menu. 7. Decide how to create the subset. You can: • Create a subset. Make sure that no existing subsets are selected, and select New from the Future Subset menu. • Base a new subset on an existing one. Select an existing subset from the Future Subsets tab, and select New As from the Future Subset menu. The Future Subset Details window appears. 15 July 2011 345 Alliance Access 7.0.20 For a description of the fields displayed in this tab, see "Future Subset Details - Part 1 Tab" on page 349. 8. In the Part 1 tab, select the required message priority from the Priority list. 9. If you selected Urgent or Normal in the Priority field, then you may define options in the Message Categories, Message Types, Branch Codes panels and also the Field 13C selection. Select from: • the category of message, by selecting the message category boxes for the message categories that you want to include • the individual message type, by typing the message type identification in the message type boxes • the branch codes by typing the required codes into the branch code boxes • the detection of messages that contain field 13C by ticking the Field 13C box • FINCopy service, by typing the service code in the message type box • a combination of the above. Note If you select System in the Priority field, then only message types can be selected. 10. In the Future Subsets menu, either select Modify to save a future subset based on an existing one, or select Add to save a new future subset. 11. In the Destination menu, select Modify. 12. If you want to add another priority, then click the Part 2 tab. 346 System Management Guide Configuring Message Delivery (Delivery Subsets) For a description of the fields displayed in this tab, see "Future Subset Details - Part 2 Tab" on page 351. 13. In the Part 2 tab, select the required message priority from the Priority list. 14. Select the Used check box. 15. If you selected Urgent or Normal in the Priority field, then you may define options in the Message Categories, Message Types, Branch Codes panels and also the Field 13C selection. For details on how to configure these options, see step 9. 16. In the Future Subsets menu, select Add. 17. In the Destination menu, select Modify. 18. If you want to add another priority, then click the Part 3 tab. For a description of the fields displayed in this tab, see "Future Subset Details - Part 3 Tab" on page 352. 15 July 2011 347 Alliance Access 7.0.20 Note The Part 3 tab is not available in the future subset if the Part 2 tab is not completed and the Used box is selected. Information in the Part 2 and Part 3 tabs is included in the future subset only if the Used check box is selected for the Parts that you want to include. 19. In the Part 3 tab, select the required message priority from the Priority list. 20. Select the Used check box. 21. If you selected Urgent or Normal in the Priority field, then you may define options in the Message Categories, Message Types, Branch Codes panels and also the Field 13C selection. For details on how to configure these options, see step 9. 22. In the Future Subsets menu, select Add. 23. In the Destination menu, select Modify. Note If you are running Alliance Access in Low Speed Mode, then you must single-click on the Destination list to refresh it after adding a delivery subset. 25.2.1 Future Subsets Tab Description From the Destination main window, double-click the Destination for which you want to define a future delivery subset. The Destination Details window appears. Click the Future Subsets tab. Example of Future Subsets tab Field descriptions Destination (shown in window title bar) The destination for which the current and future subsets appears. Name Contains the name for this delivery subset (six characters). State Defines the status of preparation of future delivery subsets. 348 System Management Guide Configuring Message Delivery (Delivery Subsets) Possible values are: • Wait MT 047 Resp, waiting for a response to the MT 047 message (Delivery Instructions Redefinition Request) generated by Alliance Access and sent to the network to request the replacement of the currently used delivery subset by those in this panel • Modified, a modification to the future subsets has occurred since the last MT 047 message was sent • No Change, no change since the last MT 047 was sent • Invalid, a delayed NAK (MT 015) to the MT 047 request was sent by FIN to inform the user that the request was cancelled. Refer to the SWIFT User Handbook, FIN System Messages. Value Date Ordering If you select the check box, then the messages are delivered in value date order within each subset. The order of delivery is: • Value-date-sensitive messages with the earliest value date are delivered first • If a message contains more than one value date field, then the field with the earliest value date is considered for value date ordering • If there are several messages queued with the same value date, then delivery is according to priority and time of queuing. Shared Subset You can specify if the subset of the destination is to be shared across LTs when receiving output. You can select one of the following options: • Share with Overflow • Share with Load Balancing. 25.2.2 Future Subset Details - Part 1 Tab Description When creating new subsets, you either select New from the Future Subset menu or select an existing subset from the Future Subsets tab, and select New As from the Future Subset menu. The Future Subset Details window appears. 15 July 2011 349 Alliance Access 7.0.20 Example of Future Subset Details - Part 1 tab Field descriptions Destination (shown in the window title bar) The destination for which the current and future subsets appears. Name The user-defined name of the future subset (this must be six characters long). Combined Criteria This field specifies whether criteria defining the delivery subset needs to be combined or not by SWIFT when queuing the output messages. You can select one of the following options: • Do Not Combine • Combine When Combine is selected, the following constraints are applicable (for each Part tab): – Field 13C should be selectable (always unchecked) – At least one branch code must be specified – Either one value (at least) must be entered in the Message Categories pane or one value (at least) must be entered in the Message Types pane (can also contain service codes), or both. Part 1 Priority Select one of the following options from the list: • System • Urgent • Normal. 350 System Management Guide Configuring Message Delivery (Delivery Subsets) Part 1 Message Categories This field enables you to select the message category (or categories) to be contained in the delivery subset. Message types belonging to the message category selected here may not be entered below. Message categories are disabled if you selected System in the Priority field. Part 1 Message Types This field enables you to specify a maximum of 10 message types (or FINCopy service), to be contained in the delivery subset. Type in the message type or service code (three alphanumeric characters). If an entry is made in this field, then the message category to which this message type belongs may not be specified in the message categories field. Note that no check is performed on the validity of the message type entered in this field. Part 1 Branch Codes This field enables you to specify a maximum of 10 message Branch Codes, for the selected destination, to be contained in the delivery subset. Type in the Branch Code (three alphanumeric characters). Note that Branch Codes are optional, "XXX" not be entered as a Branch Code, and Branch Codes cannot be used with priority "System". Also Branch Codes must be valid for the destination (not validated by Alliance Access). Part 1 Field 13C This field allows you to restrict the Delivery Subset to FIN messages that contain field 13C. Tick the Field 13C box to enable this option. Note that this option cannot be used with priority "System". 25.2.3 Future Subset Details - Part 2 Tab Description If you want to add another priority to a newly created subset, then click the Part 2 tab in the Future Subset Details window. Example of Future Subset Details - Part 2 tab 15 July 2011 351 Alliance Access 7.0.20 Field descriptions Destination (shown in the window title bar) The destination for which the current and future subsets appears. Part 2 Priority Select one of the following options from the drop-down list: • System • Urgent • Normal. Part 2 Used To include Part 2 of the panel as part of the delivery subset, select the Used check box. Part 2 Message Categories This field enables you to select the message category (or categories) to be contained in the delivery subset. Message types belonging to the message category selected here may not be entered below. Message Categories are disabled if you selected System in the Priority field. Part 2 Message Types This field enables you to specify a maximum of 10 message types and FINCopy service, to be contained in the delivery subset. Type in the message type and service code (three alphanumeric characters). If an entry is made in this field, then the message category to which this message type belongs may not be specified in the message categories field. Note that no check is performed on the validity of the message type entered in this field. Part 2 Branch Codes This field enables you to specify a maximum of 10 message Branch Codes, for the selected destination, to be contained in the delivery subset. Type in the Branch Code (three alphanumeric characters). Note that Branch Codes are optional, "XXX" cannot be entered as a Branch Code, and Branch Codes cannot be used with priority "System". Also Branch Codes must be valid for the destination (not validated by Alliance Access). Part 2 Field 13C This field allows you to restrict the Delivery Subset to FIN messages that contain field 13C. Tick the Field 13C box to enable this option. Note that this option cannot be used with priority "System". 25.2.4 Future Subset Details - Part 3 Tab Description If you want to add a third priority to a newly created subset, then click the Part 3 tab in the Future Subset Details window. 352 System Management Guide Configuring Message Delivery (Delivery Subsets) Example of Future Subset Details - Part 3 tab Field descriptions Destination (shown in the window title bar) The destination for which the current and future subsets appears. Part 3 Priority Select one of the following options from the drop-down list: • System • Urgent • Normal. Part 3 Used To include Part 3 of the panel as part of the delivery subset, select the Used check box. Part 3 Message Categories This field enables you to select the message category (or categories) to be contained in the delivery subset. Message types belonging to the message category selected here may not be entered below. Message Categories are disabled if you selected System in the Priority field. Part 3 Message Types This field enables you to specify a maximum of 10 message types (or FINCopy service), to be contained in the delivery subset. Type in the message type or service code (three alphanumeric characters). If an entry is made in this field, then the message category to which this message type belongs may not be specified in the message categories field. Note that no check is performed on the validity of the message type entered in this field. Part 3 Branch Codes This field enables you to specify a maximum of 10 message Branch Codes, for the selected destination, to be contained in the delivery subset. Type in the Branch Code (three alphanumeric characters). 15 July 2011 353 Alliance Access 7.0.20 Note that Branch Codes are optional, "XXX" cannot be entered as a Branch Code, and Branch Codes cannot be used with priority "System". Also Branch Codes must be valid for the destination (not validated by Alliance Access). Part 3 Field 13C This field allows you to restrict the Delivery Subset to FIN messages that contain field 13C. Tick the field 13C box to enable this option. Note that this option cannot be used with priority "System". 25.3 Example of Adding a Future Subset Overview If, for example, you want to create a special subset that includes only messages relating to Traveller's cheques, then you would probably want to queue Category 8 messages separately for Urgent and Normal. Currently, normal priority Category 8 messages are placed in the NORMAL subset and urgent priority are placed in the URGENT subset. To create a subset that includes all Category 8 messages: 25.4 1. In the Future Subset tab of the Destination Details window, select the URGENT subset as the template for a new subset, and then select the New As command from the Future Subset menu. The Future Subset Details window appears. 2. In the Name field, type a name for the delivery subset, for example, TRACHK. 3. To specify all urgent priority messages in Category 8, select 8 in the Message Categories section of the Part 1 tab. 4. Click the Part 2 tab. 5. In the Part 2 tab, select the Used check box. 6. Select Normal from the Priority list. 7. To select normal priority messages, click the Message Priority option button and select Normal. 8. Select 8 in the Message Categories section. 9. In the Future Subsets menu, select Add. Sending a Delivery Instructions Redefinition Request (MT 047) Rules For the rules related to sending an MT 047, see the User Handbook - FIN System Messages. To send an MT 047: 354 1. Run the SWIFT Interface application. 2. From the View menu, select Destination. System Management Guide Configuring Message Delivery (Delivery Subsets) 3. Open the destination for which you want to send an MT 047 to redefine the delivery subsets. The Destination Details window appears. 4. Click the Future Subsets tab. 5. From the Destination menu, select Redefine Delivery. The Redefine Delivery Subsets window appears. 6. In the MT 047 Sender Logical Terminal field, select a logical terminal belonging to the destination. The Redefine button is enabled. 7. In the MT 047 Sender Branch code field, you can optionally specify a branch code otherwise this field defaults to XXX. 8. Click Redefine to send the request to SWIFT. After redefining delivery subsets for a destination, make sure that the Select FIN command (available from the SWIFT Interface application main window, Logical Terminal menu) is selecting the redefined subsets. This is especially important if the names of the delivery subsets have been changed. Note 25.5 Because SWIFT cannot run an MT 047 while there are FIN sessions open for that destination, it sends a Request to Quit service request (MT 008) to all the destination's logical terminals indicating the time at which the MT 047 is processed. FIN sessions that remain open at that time are aborted. Synchronising Delivery Subsets Overview If you have just installed Alliance Access for the first time and you want to replace the system defaults with FIN subsets defined at SWIFT for your previous CBT, then you can do this by sending an MT 035 Delivery Instruction Request. An MT 035 can be generated using the Message Creation application. For more information, see "Creating Messages" in the Daily Operations Guide. In response, SWIFT sends an MT 055 Delivery Instruction Report. This is processed by Alliance Access, which replaces its current default set with the definitions contained in the MT 055. 25.6 Sharing Delivery Subsets Overview Users can select the same delivery subsets by more than one logical terminal of the same destination. This can be achieved by means of a modified APC MT 077, which must be sent between Login and Select messages, or more permanently by redefining the delivery subset as a shared subset as explained in "Defining a Future Delivery Subset". 15 July 2011 355 Alliance Access 7.0.20 To select the same delivery subset with different logical terminals from the same destination, the selection mode for these logical terminals in the SWIFT Interface application has to be modified from exclusive mode to shared mode. 25.6.1 Logical Terminals in Shared Mode Overview When a logical terminal is in shared mode, the SWIFT Interface application allows selection of both: • delivery subsets not yet selected • delivery subsets already selected by logical terminals that are also defined as shared. Exclusive delivery subsets already selected by logical terminals cannot be selected. 25.6.2 Logical Terminals in Exclusive Mode Overview When logical terminals are in exclusive mode, the SWIFT Interface application permits only the selection of delivery subsets not yet selected. 25.6.3 Changing the Selection Mode of a Logical Terminal To change the selection mode of a logical terminal: 1. Run the SWIFT Interface application. 2. From the Logical Terminal menu, select the required mode. Select: • Exclusive Mode to change a logical terminal from shared mode to exclusive mode • Shared Mode to change a logical terminal from exclusive mode to shared mode. 356 System Management Guide Import/Export of Message Templates 26 Import/Export of Message Templates Introduction You can import and export MT and MX message templates created from Alliance Workstation and Alliance Messenger. Both import and export of message templates are performed in Operational mode from the SWIFT Support application. 26.1 Import Message Templates Overview You can import templates that have created using earlier releases of Alliance Access, templates created on the UNIX platform, and MX message templates created by means of Alliance Messenger. To import a message template: 1. Start the Alliance Access servers in Operational mode. 2. Run the SWIFT Support application. 3. From the File menu, select Import Message Templates. The Import Message Templates window appears. Note The File on: field is only displayed if you are performing the operation from a Workstation. This field enables you to specify whether the file to be imported is on the Workstation or on the server. 4. If you are on a Workstation, then specify the location of the template file by selecting either Server or Local from the File on: drop-down menu. 5. Either type the pathname of the template file to be imported in the Template File field or click the browse button ( ... ) to locate it. 6. Select the format of the message templates to be imported in the Format field. • All, for MT and MX message templates • MT, for MT message templates only • MX, for MX message templates only. 7. 15 July 2011 If you selected All or MT in the Format field, then specify the syntax version against which the MT message templates must be imported. Select the appropriate syntax version from the Syntax Version field. 357 Alliance Access 7.0.20 8. Click OK to import the message templates. For each message template imported, an event is generated in the Event Journal. 26.2 Notes on Importing MT Templates Overview It is important to understand the relationship between exported templates and how the import function extracts data to create prompt templates in Alliance Access. The general principle of importing templates is that fields in block 4 of the template are compared to the syntax description for that message type. The comparison starts from the first field and continues as long as the description matches the Message Syntax Table Version (MSTV) where the templates are being imported. When the import function finds a field that is incompatible - either because the syntax description of a field does not match, or because the field itself varies from the MSTV - a fast template is created. The following examples are important to understand if you import fast templates created using an earlier release of Alliance Access, which you import and then open in prompt mode. Message syntax samples Samples of message syntax follow, along with some examples to help explain this principle. Consider the following expected syntax: MF20 OF21 Start of loop; minimum 1 maximum 10 MF32A OF53A, B, D End of loop The following illustrates the result which can occur in practice based on this syntax. Syntax in template to import Results and comments :20:TRN The result is a valid prompt template. The order and syntax of the fields match the expected syntax. :32A:980228USD100, :53B:SWIFT :32A:980303NOK250, :20:TRN :32A:980228 The result is a fast template, because the syntax of field 32A does not match the expected syntax. :53B:SWIFT :32A:980303NOK250, :20:TRN :32A:980228USD100, The result is a fast template, because the second occurrence of the loop is incorrect. :53B:SWIFT :53B:SWIFT :20:TRN The result is a prompt template. Even though the required minimum occurrence of the loop is missing, remember that templates can exist without all required fields being completed. :20:TRN The result is a fast template. The syntax description is finished, but there is still a field 53C to try to match. That field is incompatible with the expected syntax. :32A:980228USD100, :53B:SWIFT :53C:/SWIFT 358 System Management Guide Import/Export of Message Templates Extracting the data for block 4, however, can result in some fields being mapped differently in the newly created template, compared to their relative positions in the exported template. Some of the mapping differences can also result in invalid templates. The circumstances under which mapping differences may occur are best illustrated with a few examples. Example If part of the syntax is as follows: Start of loop MF35B ... OF18A End of loop MF18A and the input template contains the following information: :35B:<correct syntax> :18A:<correct syntax> then the input template is valid, but the resulting prompt template would be invalid. As soon as the import program finds field 18A, it maps to the first occurrence of that field in the expected syntax - which, in this case, is an optional field. The mandatory field is missing in this example. Example A similar situation exists if the syntax includes the following fields: Start of optional MF32F MF87 A, B or D MF34P OF53A, B or D MF57A, B or D End of sequence B Start of optional MF32F MF87A, B or MF34R MF57A, B or End of sequence C sequence B sequence C D D and the input template contains the following information: :32F:<correct :87A:<correct :34R:<correct :57A:<correct syntax> syntax> syntax> syntax> The input template is valid, however, the resulting prompt template would be invalid. Fields 32F and 87A match the beginning of sequence B, and then the mandatory field 34P is missing. Example Similar ambiguities in message syntax can result in a template that is valid, but in which the data is mapped to a different position after the template is imported. For example, consider the following syntax: Start of mandatory sequence A MF30 OF31F OF87A, D ... some optional fields End of sequence A Start of optional sequence B ... some optional fields OF87A, D End of sequence B 15 July 2011 359 Alliance Access 7.0.20 assume that the input template contains the following information: :30:<correct syntax> :87A:<correct syntax> also, assume that the template was created in prompt mode with field 87A in sequence B. After export and import, 87A would be part of sequence A instead. Example Consider also the following syntax with the following fields: Start of repetitive optional sequence B MF35B Start of loop OF83A, C or D OF23 End of loop End of sequence B Start of repetitive optional sequence C MF23 Start of loop OF83A, C or D OF35B End of loop End of sequence C and the input template is created in prompt mode and contains the following fields: :35B:<correct syntax> :23:<correct syntax> :83A:<correct syntax> Before export, field 35B was in sequence B, and fields 23 and 83A were in sequence C. After export and import the template would still be valid, but fields 23 and 83A would be in sequence B. 26.3 Exporting Message Templates Overview You can export existing templates from a designated logical terminal and store them in a single file, which is a convenient way to transfer information between Alliance Access systems. A command is available to run offline (applicable to MT messages only). For more information about this functionality, see "Exporting Templates" in the Daily Operations Guide. To export a message template: 360 1. Start the Alliance Access servers in Operational Mode. 2. Run the SWIFT Support application. 3. From the File menu, select Export Message Templates. The Export Message Templates window appears. System Management Guide Import/Export of Message Templates 4. Either type the pathname of the template file to be exported in the Template File field or click the browse button ( ... ) to locate it. 5. Select the format of the message templates to be exported in the Format field. • All, for MT and MX message templates • MT, for MT message templates only • MX, for MX message templates only. 6. If you selected All or MT in the Format field, then two additional fields are displayed. Both fields are optional and applicable to MT messages only. • Sender LT. Complete this field with a BIC12 sender logical terminal if you want only message templates for this BIC to be exported. Leave the field empty if you want all MT message templates to be exported. • Replacement LT. If you completed the Sender LT field, then this field determines the BIC12 that replaces the selected sender logical terminal during export. 7. Click OK to export the message templates. The Event Journal contains the name of each template considered for export for the selected type and indicates whether a template was exported successfully. 15 July 2011 361 Alliance Access 7.0.20 27 Increasing Message Throughput Introduction This section describes how to configure your system to maximise message throughput. It is aimed at institutions having volume traffic of over 10,000 messages per day, and particularly institutions having traffic as high as 20,000 per day with possible peaks of 6,000 messages per hour. The recommendations in this section assume that the computational power of the hardware platform matches the customer's traffic volume processing needs. 27.1 Message Throughput: A Definition Overview In this section, when the terms "messages per day" or "messages per hour" are used in relation to message throughput, it means the total number of SWIFT messages completely processed by Alliance Access in one day (during 24H from midnight) or one hour (period of 60 minutes). The processing of incoming and outgoing messages includes: • the reception, storage, and acknowledgement of messages from the SWIFT network and the transfer of those messages to a back-office application • the reception of messages from a back-office application and the sending of those messages to the SWIFT network, plus sending back the acknowledgements to back-office application. 27.2 Configuring Event Distribution Overview Using the System Management application, it is possible to modify certain parameters that can influence the operation of Alliance Access. By modifying certain normal events it is possible to economise the use of system resources. Events are either journalised in the Event Journal or ignored. By modifying certain normal events so that they are not journalised, that is, ignored, it is possible to economise the use of system resources. It is recommended to modify the distribution, for example, journalised or not journalised, of the following events: • SIS 8064 FIN Message Sent • SIS 8065 FIN Message Acked • SIS 8066 FIN Message Received • MXS 10008 Message Received • MXS 10009 Message Sent. 362 System Management Guide Increasing Message Throughput To modify an event so that it is ignored (not journalised): 1. Run the System Management application. 2. From the View menu, select Event Distribution. The Event Distribution window displays all available event types. Double-click one of the above listed events. The Event Distribution Details window appears. 27.3 3. Click Distribution and select Ignore, to specify that the event is not journalised. 4. Repeat steps 2 and 3 for each of the above listed events. Configuring the _SI_from_SWIFT Queue Overview By default, according to the predefined routing rules for the _SI_from _SWIFT queue, incoming statements and FIN messages are routed to two different reception queues. This is dependent on routing rule 100, that routes all statement messages to the routing point "Statement" and routing rule 200, that routes all other FIN messages to the routing point "Received". To economise the use of system resources, it is recommended to send all FIN messages to the same reception queue. To do this, use the Routing application to remove routing rule 100 from the _SI_from_SWIFT queue. To send all FIN messages to the same reception queue: 1. Sign on in Housekeeping mode, or use a duplicate of the active routing schema (see "Create or Modify a Routing Schema" on page 315). 2. Run the Routing application. 3. From the View menu, select Routing Point. 4. From the main Routing window, highlight the _SI_from_SWIFT queue in the Routing Point window. From the Routing Point menu, select Open. The Routing Point Details window appears. 15 July 2011 363 Alliance Access 7.0.20 5. Ensure that the Assigned to Schema field has the active schema selected. 6. Highlight routing rule 100 and select Remove from the Routing Rule menu. 7. From the File menu, select Approve. 8. From the File menu, select Activate. By deleting rule 100 from the _SI_from_SWIFT queue, all incoming FIN messages are routed to the same reception queue. 27.4 Configuring the _SI_to_SWIFT Queue Threshold Overview When you have succeeded in increasing message throughput within Alliance Access, it is necessary to modify the threshold of the _SI_to_SWIFT queue (SWIFT outbound queue), so that it can deal with the increased traffic. To modify the queue threshold: 364 1. Run the System Management application. 2. From the View menu, select Queues. 3. Double-click the _SI_to_SWIFT queue. The Queue Details window appears. 4. In the Queue Threshold field, type in a value of 10,000, or above. 5. From the Queue menu, select Modify. System Management Guide Increasing Message Throughput 27.5 Configuring Two Logical Terminals for Input and Output Overview To deal with traffic volumes of between 10,000 and 20,000 messages per day, it is recommended to have two logical terminals on two different destinations. Both logical terminals must be configured for Login and Select in input/output mode. Note It is less efficient to use one line for input and the other line for output. For information about how to configure your logical terminals, see "Managing Alliance Access Security" on page 77. 27.6 Configuring Three Message Partners Overview To optimise message throughput, it is recommended to configure at least three message partners, one for input and two for output: • an input message partner to receive messages from a back-office application • an output message partner to send ACK messages to a back-office application • an output message partner to send all other output messages to a back-office application. For more information about configuring message partners, see "Managing Message Partner Profiles" on page 243. 15 July 2011 365 Alliance Access 7.0.20 366 System Management Guide Part D - Appendices Part D Appendices 15 July 2011 367 Alliance Access 7.0.20 368 System Management Guide Appendix A - Default Profiles Appendix A Default Profiles Introduction To assist new users with initial configuration, Alliance Access provides a number of default operator profiles which are pre-configured to represent the typical duties of the following types of user: • Operator • Supervisor • RMA operator • RMA supervisor • System Administrator. These profiles may be selected when defining new operators and used as provided, or used as a template for creating personalised operator profiles. Default operator profiles may be modified, as required, or used as templates for the creation of profiles for other operators for specific duties. The tables in this section show the various entitlements and permissions, for each Alliance Access application, that are provided by the default profiles supplied with Alliance Access. See the following sections for details of the entitlements, and permissions for the standard Alliance applications. Note that, once the entitlement to "Open" an application has been granted, this also allows the use of various general facilities within that application to be used - which are not the subject of further entitlements. For example, in the Event Journal application, all operators with entitlement to open this application may search for specific events, and Open/Print those events. However, only those with a specific additional entitlement may archive the Event Journal. In the tables, the term 'Open/Print' is used where an entitlement or permission is granted, which enables an operator to open an object details window and to view (display) and, optionally, print the details currently assigned to that object. The terms "Add" or "Mod" or "Rem" are used where an entitlement or permission allows an operator to make changes to the definition of a particular object: either by adding a new object, by modifying the details of an existing object, or by removing an object altogether. Note A.1 For clarity, the 'R7.0_' prefix is omitted from the profile names in the headings of the tables. Standard Default Profiles Overview The tables in this section show the various entitlements and permissions for the default profiles, which are provided as standard with Alliance Access: • R7.0_SuperKey: The default profile R7.0_SuperKey is associated with the Alliance AccessAdministrator, which gives the administrator access to all licensed Alliance Access 15 July 2011 369 Alliance Access 7.0.20 applications. The Administrator can use the same application functions as a Supervisor, and is additionally able to create, verify, authorise, or modify messages. • R7.0_Supervisor: The default profile R7.0_Supervisor is associated with the Alliance Access Supervisor. If an operator is assigned the R7.0_Supervisor profile, then this gives the operator access to all standard Alliance Access applications, the Message Creation application, and the Message Modification application. • R7.0_Operator: This profile enables an Alliance Access operator to sign on to the SWIFT network and process messages passing between Alliance Access and other systems. • R7.0_MsgEntry: This profile enables an Alliance Access operator to create and process messages within Alliance Access, but does not allow the operator to connect to the SWIFT network or control the message flow. • R7.0_MsgPartner: The default R7.0_MsgPartner profile that is assigned to message partners sets no constraints on the messages that can be created. This profile can be modified to suit your own business needs. This profile is only used within the Application Interface to control the privileges granted to an external Message Partner, when sending prepared messages which are then "created" within Alliance Access. This profile is never used by human operators. • R7.0_RMA_Admin: The role of the Relationship Management Application (RMA) Administrator is to manage the authorisations and query messages in the Relationship Management data store. Although a Relationship Management Application Administrator cannot create or modify authorisations, a Relationship Management Application Administrator can verify and authorise outgoing messages prepared by others. Alliance Access includes a default operator profile, R7.0_RMA_Admin, to provide access to the functionality required by an RMA Administrator. • R7.0_RMA_Oper: The role of the Relationship Management Application (RMA) Operator is to create or modify an authorisation that allows a correspondent to send messages to your institution. An RMA Operator does not have the permissions, by default, to perform other tasks related to authorisation management (such as accept, reject, revoke, and so on). The default profile R7.0_RMA_Oper is associated with the RMA Operator. The R7.0_MsgEntry profile is designed to be used in combination with other profiles, and not on its own. If you want to use the R7.0_MsgEntry profile, then you must ensure that a profile which has access to the Access Control application (for example, the R7.0_Operator profile) is also assigned in the "operator definition". Although security officers do not have a configurable profile in the same way as other Alliance Access operators, the scope of their functional entitlements is also shown in the following tables, and may be contrasted with the various default profiles. For clarity, the 'R7.0_' prefix is omitted from the profile names in the headings of the tables, where applicable. Conventions used in operator profile tables The following conventions are used in the tables that outline the default entitlements for operator profiles: • Entitlements for each application are listed by function. • Some functions have additional permissions, and these functions have an asterisk (*) after their name in Alliance Access. The additional permissions are listed in the Specific permissions column in the tables, and their default values are listed in the operator profile columns. 370 System Management Guide Appendix A - Default Profiles • A checkmark (✓) or value in the column of an operator profile means that the operator profile has entitlements to access or use the application or function. • A dash (-) in the column of an operator profile means that the operator has no entitlements to access or use the application or function. • If an operator profile is not listed for an application, it signifies that there are no default entitlements for that profile. A.1.1 Access Control Application Entitlements and permissions within the Access Control application Entitlement Specific permissions LSO/RSO Super Key Supervisor Import Export Operator RMA Admin Open application None ✓ ✓ ✓ ✓ ✓ - Signon Start Time 1 0000 0000 0000 - 0000 - End Time 1 2357 2357 2357 - 2357 - Start Time 2 2358 2358 2358 - 2358 - End Time 2 2359 2359 2359 - 2359 - Bank Query None ✓ ✓ ✓ - - - Files on Server None - ✓ ✓ ✓ - ✓ Embedded Checks None - ✓ ✓ - - - A.1.2 Application Interface Application Entitlements and permissions within the Application Interface application Entitlement Specific permissions Super Key Supervisor Import Export Operator Msg Partner Open Application None ✓ ✓ ✓ ✓ ✓ Abort Session Message Partner(s) (Allowed/Prohibited) None prohibited None prohibited - None prohibited - Add Exit Point None ✓ ✓ ✓ - - Add Partner Local Authentication Key: First part (Yes/No) Yes Yes Yes - - Second part (Yes/No) Yes Yes Yes - - First part (Yes/No) Yes Yes Yes - - Second part (Yes/No) Yes Yes Yes - - Own destination (Allowed/Prohibited) None prohibited - - - None prohibited MT (Allowed/Prohibited) None prohibited - - - None prohibited Session Authentication Key: Create Message 15 July 2011 371 Alliance Access 7.0.20 Entitlement Specific permissions Super Key Supervisor Import Export Operator Msg Partner CCY+[AMOUNT] (Allowed/Prohibited) None prohibited - - - None prohibited Service $ identifier (Allowed/Prohibited) None prohibited - - - None prohibited Bypass verify MT (Allowed/Prohibited) 999 allowed - - - None prohibited Bypass verify CCY (Allowed/Prohibited) None prohibited - - - None prohibited Bypass auth. MT (Allowed/Prohibited) 999 allowed - - - None prohibited Bypass auth. CCY (Allowed/Prohibited) None prohibited - - - None prohibited Bypass authorisation: Service $ identifier (Allowed/Prohibited) None prohibited - - - None prohibited Enable Mess. Partner None ✓ ✓ - - - Mod Exit Point None ✓ ✓ ✓ - - Mod Partner Local Authentication Key: First part (Yes/No) Yes Yes Yes - - Second part (Yes/No) Yes Yes Yes - - First part (Yes/No) Yes Yes Yes - - Second part (Yes/No) Yes Yes Yes - - Move to Routing Point None ✓ - - - ✓ Open/Print Exit Point Exit Points (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited - Open/Print Partner Local Authentication Key: First part (Yes/No) Yes Yes Yes No - Second part (Yes/No) Yes Yes Yes No - First part (Yes/No) Yes Yes Yes No - Second part (Yes/No) Yes Yes Yes No - Message Partners (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited - Rem Exit Point None ✓ ✓ - - - Rem Partner Local Authentication Key: First part (Yes/No) Yes Yes - - - Second part (Yes/No) Yes Yes - - - Dispose Message Session Authentication Key: Session Authentication Key: 372 System Management Guide Appendix A - Default Profiles Entitlement Specific permissions Super Key Supervisor Import Export Operator Msg Partner First part (Yes/No) Yes Yes - - - Second part (Yes/No) Yes Yes - - - Run Session Message Partner(s) (Allowed/Prohibited) None prohibited None prohibited - None prohibited - Start Session Message Partner(s) (Allowed/Prohibited) None Prohibited None prohibited - None prohibited - Stop Session Message Partner(s) (Allowed/Prohibited) None prohibited None prohibited - None prohibited - Session Authentication Key: A.1.3 Calendar Application Entitlements and permissions within the Calendar application Entitlement Specific permissions Super Key Supervisor Open Application None ✓ ✓ Add Calendar None ✓ ✓ Add Calendar Year None ✓ ✓ Default Calendar Year None ✓ ✓ Modify Calendar Year None ✓ ✓ Open/Print Calendar None ✓ ✓ Remove Calendar None ✓ ✓ Remove Calendar Year None ✓ ✓ A.1.4 Correspondent Information File Application Entitlements and permissions within the Correspondent Information File application Entitlement Specific permissions Super Key Supervisor Import Export Operator Open Application None ✓ ✓ ✓ ✓ Add Alias None ✓ ✓ - ✓ Add Correspondent None ✓ ✓ ✓ - Add Country None ✓ ✓ - - Add Currency None ✓ ✓ - - Install Bankfile Store schedule (Yes/ No) Yes Yes - - Modify operating mode (Yes/No) Yes Yes - - None ✓ ✓ - ✓ Modify Alias 15 July 2011 373 Alliance Access 7.0.20 Entitlement Specific permissions Super Key Supervisor Import Export Operator Modify Corr Dets (Correspondent details) None ✓ ✓ ✓ ✓ Modify Country None ✓ ✓ - - Modify Currency None ✓ ✓ - - Open/Print Alias None ✓ ✓ - ✓ Open/Print Corr Dets (Correspondent details) None ✓ ✓ ✓ ✓ Open/Print Country None ✓ ✓ - ✓ Open/Print Currency None ✓ ✓ - ✓ Remove Alias None ✓ ✓ - - Remove Correspondent None ✓ ✓ - - Remove Country None ✓ ✓ - - Remove Currency None ✓ ✓ - - A.1.5 Event Journal Application Entitlements and permissions within the Event Journal application Entitlement Specific permissions LSO/RSO Super Key Supervisor Open Application None ✓ ✓ ✓ Archive Store schedule (Yes/No) - Yes Yes Modify operating mode (Yes/No) - Yes Yes A.1.6 Message Approval Application Entitlements and permissions within the Message Approval application Entitlement Specific permissions Super Key Supervisor Msg Entry Open Application None ✓ ✓ ✓ Approve Message Own destination (Allowed/Prohibited) None prohibited None prohibited None prohibited Can Verify (Yes/No) Yes Yes Yes Can Authorise (Yes/No) Yes Yes No Verify own entered Mesg (Yes/No) Yes No No Auth. own entered Mesg (Yes/No) Yes No No 374 System Management Guide Appendix A - Default Profiles Entitlement Specific permissions Super Key Supervisor Msg Entry Auth. own verified Mesg (Yes/No) Yes No No Group Authorise (Yes/No) Yes No No CCY/Amount (Allowed/Prohibited) None prohibited None prohibited None prohibited Swift FIN User MT (Allowed/Prohibited) None prohibited None prohibited None prohibited Swift FIN System MT (Allowed/Prohibited) None prohibited None prohibited None prohibited Swift APC System MT (Allowed/Prohibited) None prohibited None prohibited None prohibited Service $ identifier (Allowed/Prohibited) None prohibited None prohibited None prohibited Bypass Authorisation for CCY/Amount (Allowed/Prohibited) None prohibited - None prohibited Bypass Authorisation for Swift FIN User MT (Allowed/Prohibited) None prohibited - 999 allowed Route Message None ✓ - - Treat Recovered Msg Own destination (Allowed/Prohibited) None prohibited None prohibited - Group Authorise (Yes/No) Yes Yes - Dispose Message A.1.7 Message Creation Application Entitlements and permissions within the Message Creation application Entitlement Specific permissions Super Key Supervisor Msg Entry Open Application None ✓ - ✓ Add/Mod/Rem Template None ✓ - - Create Message List of Own-Destination (Allowed/Prohibited) None prohibited None prohibited None prohibited Can create broadcasting (Yes/No) Yes - No CCY/Amount (Allowed/Prohibited) None prohibited - None prohibited Swift FIN User MT (Allowed/Prohibited) None prohibited - None prohibited Swift FIN System MT (Allowed/Prohibited) None prohibited - None prohibited 15 July 2011 375 Alliance Access 7.0.20 Entitlement Dispose Message Route Message A.1.8 Specific permissions Super Key Supervisor Msg Entry Swift APC System MT (Allowed/Prohibited) None prohibited - None prohibited Multiple Retrieval Allowed for SWIFTNet FIN System Messages (Yes/No) Yes - No Multiple Retrieval Allowed Yes for APC System Messages (Yes/No) - No SWIFTNet FINCopy Allowed (Yes/No) Yes - No Service $ identifier (Allowed/Prohibited) None prohibited - None prohibited Bypass Verification CCY/ Amount (Allowed/Prohibited) None prohibited - None prohibited Bypass Authorisation CCY/Amount (Allowed/Prohibited) None prohibited - None prohibited Bypass Verification Swift FIN User MT (Allowed/Prohibited) None prohibited - 999 allowed Bypass Authorisation Swift FIN User MT (Allowed/Prohibited) None prohibited - 999 allowed Bypass Authorisation Swift FIN System MT (Allowed/Prohibited) None prohibited - None prohibited Bypass Authorisation Swift APC System MT (Allowed/Prohibited) None prohibited - None prohibited Bypass authorisation: service $ identifier (Allowed/Prohibited) None prohibited - None prohibited None ✓ - - Message Modification Application Entitlements and permissions within the Message Modification application Entitlement Specific permissions Super Key Msg Entry Open Application None ✓ ✓ Bypass Security None ✓ - Complete Message (that is, discard the message) None ✓ ✓ 376 System Management Guide Appendix A - Default Profiles Entitlement Specific permissions Super Key Msg Entry Dispose Message Bypass Verification CCY/ Amount (Allowed/Prohibited) None prohibited None prohibited Bypass Authorisation CCY/ Amount (Allowed/Prohibited) None prohibited None prohibited Bypass Verification Swift FIN User MT (Allowed/Prohibited) None prohibited 999 allowed Bypass Authorisation Swift FIN None prohibited User MT (Allowed/Prohibited) 999 allowed Bypass Authorisation Swift FIN None prohibited System MT (Allowed/Prohibited) None prohibited Bypass Authorisation Swift APC System MT (Allowed/Prohibited) None prohibited None prohibited Bypass authorisation: service $ identifier (Allowed/Prohibited) None prohibited None prohibited Own destination Allowed/ Prohibited None prohibited None prohibited Mod. in Text_modification queue (Yes/No) Yes Yes Mod. in Emission_security queue (Yes/No) Yes No Mod. in Transmission_modif queue (Yes/No) Yes Yes Mod. in Modif_after_recept queue (Yes/No) Yes Yes Mod. in Reception_security queue (Yes/No) Yes No CCY/Amount (Allowed/Prohibited) None prohibited None prohibited Swift FIN User MT (Allowed/Prohibited) None prohibited None prohibited Swift FIN System MT (Allowed/Prohibited) None prohibited None prohibited Swift APC System MT (Allowed/Prohibited) None prohibited None prohibited Multiple Retrieval Allowed for FIN System Mesg (Yes/No) Yes Yes Multiple Retrieval Allowed for APC System Mesg (Yes/No) Yes Yes Modify Message 15 July 2011 377 Alliance Access 7.0.20 Entitlement Route Message A.1.9 Specific permissions Super Key Msg Entry SWIFTNet FINCopy Allowed (Yes/No) Yes Yes Service $ identifier (Allowed/Prohibited) None prohibited None prohibited None ✓ - Message File Application Entitlements and permissions within the Message File application Entitlement Specific permissions LSO/RSO Super Key Supervisor Open Application None ✓ ✓ ✓ Archive Store schedule (Yes/ No) - Yes Yes Modify operating mode (Yes/No) - Yes Yes Change priority None - ✓ ✓ Complete Instance None - ✓ ✓ Count Completely hide messages of other units (Yes/No) ✓ (No) ✓ (No) ✓ (No) Move Instance None - ✓ ✓ Re-activate Instance None - ✓ ✓ Re-assign Instance None - ✓ ✓ Search Completely hide messages of other units (Yes/No) No No No A.1.10 Monitoring Application Entitlements and permissions within the Monitoring application Entitlement Specific permissions LSO/RSO Super Key Supervisor Operator Open Application None ✓ ✓ ✓ - Abort File Transfer None - ✓ ✓ ✓ Hold Queue None ✓ ✓ ✓ - Release Queue None ✓ ✓ ✓ - Reset EProf Counter None ✓ ✓ ✓ - Reset LT Counter None ✓ ✓ ✓ - Reset MP Counter None ✓ ✓ ✓ - 378 System Management Guide Appendix A - Default Profiles Entitlement Specific permissions LSO/RSO Super Key Supervisor Operator Reset RProf Counter None ✓ ✓ ✓ - Stop Process None ✓ ✓ - - A.1.11 Relationship Management Application Relationship Management default operators R7.0_RMA_Oper and R7.0_RMA_Admin are default operator profiles that provide entitlements for using the Relationship Management application in Alliance Access. These profiles are designed to be used with other profiles, and not on their own. If you want to use the Relationship Management application, then you must ensure that a profile which has access to the Access Control application (for example, the R7.0_Operator profile) is also assigned in the operator definition. The RMA_Oper and RMA_Admin entitlements and permissions are described in the following table. Users with the R7.0_RMA_Oper profile have permission to view, print, create, modify, and add comments to authorisations. In addition, they have permission to send and respond to queries about authorisations and business relationships. However, the R7.0_RMA_Oper profile does not grant users the entitlements for functions that affect the active (or "live") authorisation, such as activating authorisations, revoking, accepting, rejecting them, or for cleaning up the database. Users with the R7.0_RMA_Admin profile can perform those actions. The permissions in both default profiles include the Four-Eyes principles by default because the Bypass approval permissions are set to "No". This means that one user must approve the actions of another user. For more information about relationship management, see the Relationship Management Application User Guide. Entitlements and permissions within the Relationship Management application The following table lists only the operators that have entitlements to access or use the application or function. The following operators have no default entitlements and are not listed: • LSO/RSO • Supervisor • Operator • R7.0_Import_Export • MsgEntry • R7.0_MsgPartner Entitlement Specific permissions Super Key RMA_ Admin RMA_ Oper Open Application None ✓ ✓ ✓ Accept Auth Destinations (Allowed/Prohibited) None prohibited None prohibited - Services (Allowed/Prohibited) None prohibited None prohibited - 15 July 2011 379 Alliance Access 7.0.20 Entitlement Specific permissions Super Key RMA_ Admin RMA_ Oper Bypass Approval (Yes/No) No No - Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited Services (Allowed/Prohibited) None prohibited None prohibited None prohibited App Granularity Dest None ✓ ✓ - Approve Auth Destinations (Allowed/Prohibited) None prohibited None prohibited - Services (Allowed/Prohibited) None prohibited None prohibited - Approve own Actions (Yes/No) No No - Approve Create (Yes/No) Yes Yes - Approve Revoke (Yes/No) Yes Yes - Approve Accept (Yes/No) Yes Yes - Approve Reject (Yes/No) Yes Yes - Approve Delete (Yes/No) Yes Yes - Clean up Auth None ✓ ✓ - Create Auth Destinations (Allowed/Prohibited) None prohibited - None prohibited Services (Allowed/Prohibited) None prohibited - None prohibited Bypass Approval (Yes/No) No - No Def Granularity Dest None ✓ ✓ - Def Signing BIC T&T None ✓ ✓ - Delete Auth Destinations (Allowed/Prohibited) None prohibited None prohibited - Services (Allowed/Prohibited) None prohibited None prohibited - Bypass Approval (Yes/No) No No - Destinations (Allowed/Prohibited) None prohibited None prohibited - Answer Message Delete Query/Answer 380 System Management Guide Appendix A - Default Profiles Entitlement Specific permissions Super Key RMA_ Admin RMA_ Oper Services (Allowed/Prohibited) None prohibited None prohibited - Destinations (Allowed/Prohibited) None prohibited None prohibited - Services (Allowed/Prohibited) None prohibited None prohibited - Store Schedule (Yes/No) Yes Yes - Modify operating mode (Yes/No) Yes Yes - Export on Change None ✓ ✓ - Import Auth Destinations (Allowed/Prohibited) None prohibited None prohibited - Services (Allowed/Prohibited) None prohibited None prohibited - Store Schedule (Yes/No) Yes Yes - Modify operating mode (Yes/No) Yes Yes - Mark Obsolete Auth(1) None ✓ ✓ - Mod Signing BIC T&T Destinations Allowed/ Prohibited None prohibited None prohibited - Modify Auth Destinations (Allowed/Prohibited) None prohibited - None prohibited Services (Allowed/Prohibited) None prohibited - None prohibited Bypass Approval (Yes/No) No - No Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited Services (Allowed/Prohibited) None prohibited None prohibited None prohibited Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited Services (Allowed/Prohibited) None prohibited None prohibited None prohibited Destinations (Allowed/Prohibited) None prohibited None prohibited - Services None prohibited None prohibited - Export Auth Open/Print Auth Det Query Message Reject Auth 15 July 2011 381 Alliance Access 7.0.20 Entitlement Specific permissions Super Key RMA_ Admin RMA_ Oper Bypass Approval (Yes/No) No No - Destinations (Allowed/Prohibited) None prohibited None prohibited - Services (Allowed/Prohibited) None prohibited None prohibited - Bypass Approval (Yes/No) No No - Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited Services (Allowed/Prohibited) None prohibited None prohibited None prohibited (Allowed/Prohibited) Revoke Auth Treat Query/Answer (1) This parameter is only applicable for users of the Relationship Management package on the Alliance Web Platform. A.1.12 Routing Application Entitlements and permissions within the Routing application Entitlement Specific permissions LSO/RSO Super Key Supervisor Import Export Open Application None ✓ ✓ ✓ ✓ Activate Schema None - ✓ ✓ - Add Keyword None - ✓ ✓ ✓ Add Rule None - ✓ ✓ ✓ Add Schema None - ✓ ✓ ✓ Approve Schema None ✓ ✓ ✓ - Def Rule None - ✓ ✓ ✓ Mod Keyword None - ✓ ✓ ✓ Mod Rule None - ✓ ✓ ✓ Mod Schema None - ✓ ✓ ✓ Open Routing Point Routing Points - None prohibited None prohibited None prohibited Rem Keyword None - ✓ ✓ - Rem Rule None - ✓ ✓ ✓ Rem Schema None - ✓ ✓ - 382 System Management Guide Appendix A - Default Profiles A.1.13 Security Definition Application Entitlements and permissions within the Security Definition application Entitlement Specific permissions LSO/RSO Super Key Supervisor Import Export Open Application None ✓ ✓ ✓ ✓ Add Operator None ✓ ✓ ✓ ✓ Add Profile None ✓ ✓ ✓ ✓ Add Unit None - ✓ ✓ ✓ Approve LDAP Approve Left or Approve Right part ✓ - - - Approve Operator Approve Left or Right part (Left/Right) Left - - - Approve Unit - - ✓ ✓ - Auth Server Config Left Secret (Yes/No) Yes - - - Right Secret (Yes/No) Yes - - - Configure LDAP None ✓ - - - Create Op List None ✓ - - - Disable Operator None ✓ ✓ ✓ - Display Auto Password(1) None ✓ - - - Enable Operator None ✓ ✓ ✓ - Mod Component None ✓ ✓ ✓ - Mod Operator None ✓ ✓ ✓ ✓ Mod Profile None ✓ ✓ ✓ ✓ Mod Security Parameters(1) None ✓ - - - Mod Unit None - ✓ ✓ ✓ Rem Operator None ✓ ✓ ✓ - Rem Profile None ✓ ✓ ✓ - Rem Unit None - ✓ ✓ - Reset User Password(1) None ✓ - - - Reset Peer Officer Password(1) None ✓ - - - (1) These entitlements cannot be re-assigned directly to other operators. However, if an operator is given the entitlement to Approve Operators, this also allows the operator to display and print other operators' system passwords and reset operators' user passwords. The Mod Security Parameters and Reset Peer Officer Password entitlements are unique to the LSO/RSO and cannot be assigned to other operators. Also, the LSO/RSO can only use the Reset Peer Officer Password entitlement if the Password: Reset Peer Officer Pwd security parameter has previously been set to Yes. 15 July 2011 383 Alliance Access 7.0.20 A.1.14 SWIFT Interface Application Entitlements and permissions within the SWIFT Interface application Entitlement Specific permissions Super Key Supervisor Import Export Operator Open Application None ✓ ✓ ✓ ✓ Add Action None ✓ ✓ ✓ - Ena / Dis Auto Mode (Enable/Disable ) None ✓ ✓ ✓ - Ena / Dis Re-Connect (Enable/Disable) None ✓ - ✓ - Login/Select None ✓ ✓ - ✓ Modify Action None ✓ ✓ ✓ - Modify LT None ✓ ✓ ✓ - Modify Subsets None ✓ ✓ ✓ - Own Destination List List Own Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited Redefine Delivery None ✓ ✓ - - Remove Action None ✓ ✓ ✓ - A.1.15 SWIFT Support Application Entitlements and permissions within the SWIFT Support application Entitlement Specific permissions Super Key Supervisor Import Export Operator Open Application None ✓ ✓ ✓ ✓ Activate VAS None ✓ - - - Add Keyword None ✓ ✓ ✓ - Add LT None ✓ ✓ ✓ - Approve FCS None ✓ ✓ - - Configure FCS None ✓ ✓ - - De-activate VAS None ✓ - - - De-install VAS None ✓ ✓ - - Export Msg Templates None ✓ - - - Import Msg Templates None ✓ - - - Install Msg Standard None ✓ ✓ - - Install Syntax (Message Syntax Table) None ✓ ✓ - - Install VAS None ✓ ✓ - - 384 System Management Guide Appendix A - Default Profiles Entitlement Specific permissions Super Key Supervisor Import Export Operator Manage ASP None ✓ ✓ - - Modify Keyword None ✓ ✓ ✓ - Modify LT None ✓ ✓ ✓ - Modify VAS None ✓ - - - Own Destination List Own Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited Rem Keyword None ✓ ✓ - - Remove Msg Standard None ✓ ✓ - - Report FCS None ✓ ✓ - ✓ Set Default Live None ✓ ✓ ✓ - Set Default T&T None ✓ ✓ ✓ - A.1.16 SWIFTNet Interface Application Entitlements and permissions within the SWIFTNet Interface application Entitlement Specific permissions Super Key Supervisor Import Export Operator Open Application None ✓ ✓ ✓ ✓ Activate EProf None ✓ ✓ - ✓ Activate RProf None ✓ ✓ - ✓ Add EProf None ✓ ✓ ✓ - Add RProf None ✓ ✓ ✓ - Adopt IChan None ✓ ✓ ✓ - Adopt OChan None ✓ ✓ ✓ - Create IChan None ✓ ✓ - - Create OChan None ✓ ✓ - - Deactivate EProf None ✓ ✓ - ✓ Deactivate RProf None ✓ ✓ - ✓ Delete IChan None ✓ ✓ - - Delete OChan None ✓ ✓ - - Disable EProf None ✓ ✓ ✓ - Disable EProf Auto None ✓ - ✓ - Disable RProf None ✓ ✓ - - Disable RProf Auto None ✓ - - - Enable EProf None ✓ ✓ - - Enable EProf Auto None ✓ - ✓ - 15 July 2011 385 Alliance Access 7.0.20 Entitlement Specific permissions Super Key Supervisor Import Export Operator Enable RProf None ✓ ✓ - - Enable RProf Auto None ✓ - ✓ - Modify EProf None ✓ ✓ ✓ - Modify RProf None ✓ ✓ ✓ - Open/Print EProf Services (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited Own Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited Open/Print IChan Own Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited Open/Print OChan Own Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited Open/Print RProf RT None ✓ ✓ ✓ ✓ Open/Print RProf SnF Own Destinations (Allowed/Prohibited) None prohibited None prohibited None prohibited None prohibited Remove EProf None ✓ ✓ - - Remove IChan None ✓ ✓ - - Remove OChan None ✓ ✓ - - Remove RProf None ✓ ✓ - - RT File Get Request Service(s) (Allowed/Prohibited) Request type(s) (Allowed/Prohibited) None prohibited None prohibited None prohibited - - Schedule EProf Add Action (Yes/No) Yes No Yes - Modify Action (Yes/No) Yes No Yes - Remove Action (Yes/ No) Yes No Yes - Add Action (Yes/No) Yes No Yes - Modify Action (Yes/No) Yes No Yes - Remove Action (Yes/ No) Yes No Yes - Schedule RProf A.1.17 SWIFTNet Support Application Entitlements and permissions within the SWIFTNet Support application Entitlement Specific permissions LSO RSO Super Key Supervisor Import Export SNL Handling Connection Handling (Yes/No) Yes Yes Yes Yes Yes 386 System Management Guide Appendix A - Default Profiles Entitlement Specific permissions LSO RSO Super Key Supervisor Import Export First Part Local Authentication Key (Yes/No) Yes No Yes Yes No Second Part Local Authentication Key (Yes/No) No Yes Yes Yes No Reset Connection Status (Yes/No) Yes Yes Yes Yes No A.1.18 System Management Application Entitlements and permissions within the System Management application Entitlement Specific permissions LSO/RSO Super Key Supervisor Import Export Open Application None ✓ ✓ ✓ ✓ Add Device None ✓ ✓ ✓ - Add Dist. List None ✓ ✓ ✓ ✓ Add Queue None - ✓ ✓ ✓ Backup (Software, Data, and Archives) Store schedule (Yes/ No) No Yes Yes - Modify operating mode (Yes/No) No Yes Yes - Hold Queue None ✓ ✓ ✓ - Manage Rec Backup(1) None ✓ ✓ ✓ - Mod Config. Param. None ✓ ✓ ✓ ✓ Mod Device None ✓ ✓ ✓ - Mod Dist. List (Distribution list) None ✓ ✓ ✓ - Mod Event Dist. (Distribution) None ✓ ✓ ✓ ✓ Mod Queue None ✓ ✓ ✓ ✓ Release Queue None - ✓ ✓ - Rem Device None ✓ ✓ ✓ - Rem Dist. List (distribution list) None ✓ ✓ ✓ - Rem Queue None - ✓ ✓ - Reset Event Distribution None ✓ ✓ ✓ - Restart SWIFTAlliance Store schedule No Yes Yes - Modify operating mode (Yes/No) No Yes Yes - 15 July 2011 387 Alliance Access 7.0.20 Entitlement Specific permissions LSO/RSO Super Key Supervisor Import Export Restore (Data, and Archives) None - ✓ ✓ - Stop SWIFTAlliance Store schedule (Yes/ No) No Yes Yes - Modify operating mode (Yes/No) No Yes Yes - None ✓ ✓ ✓ - Stop/Start Component (1) Only effective if option 14:DATABASE RECOVERY is licensed. A.2 Printout of Default Routing Rules Overview You can produce a printed document of all routing rules from the Routing application. The content of the printed document may vary, depending on the licence present. For examples of default routing rules, see the Default Printouts on the release media, or on www.swift.com, under Support > Documentation (User Handbook). 388 System Management Guide Appendix B - Default Settings Appendix B Default Settings Introduction This section describes the default settings in Alliance Access. B.1 Types of Settings Overview There are two types of default settings in Alliance Access: • fixed settings • non-fixed settings. B.1.1 Fixed Settings Overview The following is a brief overview of fixed settings in Alliance Access: • the security officer's profile • fixed event distribution • various installation parameters • UNIX only: the size of modal windows and dialog boxes B.1.2 Non-Fixed Settings Overview The following is a list of default settings that can be changed in the system: • non-fixed event distribution • alarm distribution • operator profiles • routing rules • message partner profiles • system configuration parameters • security configuration parameters • queue parameters. 15 July 2011 389 Alliance Access 7.0.20 Note B.2 When changes are made to the non-fixed settings supplied with the system, the original setting is overwritten. There is no way to revert back to the original settings automatically. However, one exception to this is the event distribution settings. Default Event Distribution Overview The default setting for event distribution is "Journalise", for example, all events are sent to the Event Journal. The default setting for event distribution concerns only the journalising option. The System Management application manages this setting. The exact field used to set event distribution is the Distribution field in the Event Distribution Details window. B.2.1 Revert to Default Settings Introduction A feature exists in Alliance Access whereby you can reset the default event distribution for all event types. This is achieved using the command Reset Default Distribution. To revert to default settings: B.3 1. Run the System Management application. 2. Select Reset default distribution from the File menu. After this command is run, all existing settings for event distribution for every event type are replaced by the default settings. Default Alarm Distribution Overview The default setting for alarm distribution is to send alarms to "All Operators" - all operators currently signed onto the system. At your site, this may not be desirable. In this case, you set up your own alarm distribution list. You can also distribute the alarms to internal correspondents. To do this, use the Distribution Lists Details window to specify the operators who can receive the alarm, and to specify the internal correspondents. The System Management application manages this setting. The Distribution Lists Details window allows you to specify who receives the alarm. You use the Event Distribution Details window to establish the link between a specific event/alarm and the distribution list. B.4 Default Operator Profiles Overview You can find a list of the default operators and operator profiles in the Default Printouts on the release media, or on www.swift.com, under Support > Documentation (User Handbook) 390 System Management Guide Appendix B - Default Settings Each profile specifies particular applications and functions which become available when assigned to an operator. These functions are designed to match the business level activities that the assigned operator performs. In addition to the operator profiles, the system is supplied with two profiles for the left security officer and right security officer. These profiles are fixed and cannot be accessed or changed by any user of Alliance Access. For more information about default operator profiles within each Alliance Access application, see Appendix A, "Default Profiles" on page 369. B.5 Default Queue Visibility and Modification Rules Overview From the System Management application, you can designate queues as visible or invisible to the Routing application. Similarly, it is also possible to permit or deny modification to the routing rules of particular routing points. In the System Management application, some queues are assigned as not visible or not modifiable by default. When a queue is assigned as not visible to the Routing application, then queue modification is also denied. The following table illustrates these default assignments. 15 July 2011 Queue name Visible in Routing application Modifiable in Routing application BatchMXAcks False False BatchMXRejects False False BatchSwiftAcks False False BatchSwiftNaks False False DeliveryNotifAcks False False DeliveryNotifNaks False False FileActAcks False False FileActReceived False False FileActReject False False FileDeliveryNotifAck False False FileDeliveryNotifNak False False LocalMXAcks False False LocalMXRejects False False LocalSwiftAcks False False LocalSwiftNaks False False MxDeliveryNotifAcks False False MxDeliveryNotifNaks False False MxReceived False False MXSystem False False MxToBeInvestigated False False 391 Alliance Access 7.0.20 392 Queue name Visible in Routing application Modifiable in Routing application Received False False Statement False False System False False ToBeInvestigated False False UpdateKeys False False AI_to_APPLI False False _AI_from_APPLI False False _MP_authorisation False False _MP_creation False False _MP_mod_emi_secu False False _MP_mod_rec_secu False False _MP_mod_reception False False _MP_mod_text False False _MP_mod_transmis False False _MP_verification False False _OI_to_OTHER True True _RMA_acked False False _RMA_nacked False False _RMA_non_delivered False False _RMA_received False False _RMA_send False False _RMA_send_msg False False _RMA_send_msg_flow False False _SI_delivery_subset False False _SI_from_SWIFT True True _SI_from_SWIFTNet True True _SI_system_msg False False _SI_to_SWIFT True True _SI_to_SWIFTNet True True _SS_alarm_creation False False _TR_NOTIF True True _TR_RREC False False Unroutable False False System Management Guide Appendix B - Default Settings B.6 Default Message Partner Profiles Default profiles You can find a list of the default message partner profiles in the Default Printouts on the release media, or on www.swift.com, under Support > Documentation (User Handbook) B.7 Default Security Configuration Parameters Overview Alliance Access also uses a number of security configuration parameters which security officers can adjust to suit the security requirements of their site. The Security Definition application manages the security configuration parameters. Most security configuration parameters are shipped with default settings. For a complete list of the configuration parameters, together with their default settings, see "Security Parameters" on page 102. B.8 Default System Configuration Parameters Overview Alliance Access uses a number of system configuration parameters. Privileged operators can use the System Management application to change these parameters to suit the business requirements of their site. Most system configuration parameters are shipped with default settings. For a complete list of the configuration parameters, and their default settings, see "Configuring System Parameters" on page 158. 15 July 2011 393 Alliance Access 7.0.20 Appendix C Queues and Message Processing Functions Introduction This section describes the Alliance queues and the processing results returned by the associated Message Processing Functions. Queues are grouped into two classes: • system queues • exit queues System queues are defined at installation time and are necessary for Alliance Access to operate properly. Users cannot remove system queues. An exit queue is user-definable and specific to an Alliance Access site. Exit queues are attached to Network Interfaces, such as APPLI, SWIFT. In the case of APPLI, exit queues can be created and removed by users. There is only one Message Processing Function associated with all the exit queues attached to APPLI (_AI_to_APPLI). The exit queues described in this section are those provided by default. Messages in Alliance Access are said to be queued at routing points where Message Processing Functions process them. A Message Processing Function can perform the following actions: • Retrieve a message from an input queue • Write a message to an output queue • Process a message according to some functional purpose • Return a processing result to the routing software. The routing software analyses the routing rules to find a routing condition corresponding to the processing result returned by the Message Processing Function. When a matching condition is found, the associated routing action is carried out. In general, system queues are processed by their own private Message Processing Functions but, when the processing requirements of system queues are closely related, the same Message Processing Function can be assigned to several queues. C.1 List of System Queues Overview This section describes the system queues defined in Alliance Access. _AI_from_APPLI (AI Inbound Queue) All messages entering Alliance Access through the Application Interface (AI) are queued at one single point of entry, before being routed onwards. This single queue is used for all AI input sessions, regardless of the connection method used by the message partner and regardless of the message format. Acceptance criteria: Creator MPF must be AI_from_APPLI. Assigned MPF: AI_from_APPLI 394 System Management Guide Appendix C - Queues and Message Processing Functions With the default routing rules, this MPF returns the following result: • Success: The message was added successfully onto the AI inbound queue. This MPF can also return the following results: • Failure • Disposition Error: The message partner details do not allow the message to be disposed in the AI inbound queue. • Original Broadcast _AI_waiting_ack This queue holds the messages sent from a standalone Alliance Access system. This queue is only visible if you have licence option 07:STANDALONE REC. Acceptance criteria: Any message is accepted. Assigned MPF: AI_from_APPLI With the default routing rules, this MPF returns the following result: • Success: The message was added successfully onto the AI inbound queue. This MPF can also return the following results: • Failure • Disposition Error: The message partner details do not allow the message to be disposed in the AI inbound queue. • Original Broadcast _MP_authorisation (Message Authorisation Queue) The queue of messages awaiting authorisation consists of: • Messages verified by the Message Approval application (the default message flow). These messages include those NAK'd by SWIFT and routed to verification from the modification queue. • SWIFT MT 999 messages, SWIFT FIN System Messages, and SWIFT APC system messages created by an operator through the Message Creation application. • FIN messages created by an operator through the Message Creation application, or messages manually corrected through the Message Modification application (including those NAK'd by SWIFT), provided the operator has the proper entitlements and permissions to move these messages directly into the authorisation queue. • Messages in CAS format received through the Application Interface when the disposition state requested by the CAS protocol specifies "Authorise" or when routing point "MP_authorisation" is requested. • Messages received through the Application Interface, if the message partner does not have the permission to bypass authorisation. Acceptance criteria: Message instance cannot be a notification. Assigned MPF: mpa 15 July 2011 395 Alliance Access 7.0.20 With the default routing rules, this MPF returns the following result: • Success: The message was processed successfully and is valid. Messages for the SWIFT network that produce this result are routed to the SWIFT outbound queue (_SI_to_SWIFT). Messages for the application (APPLI) network that produce this result are routed to an exit point specified in the message. This MPF can also return the following result: • Failure _MP_creation (Message Creation) This is a transient queue for messages created by an operator through the Message Creation application, that is, FIN user-to-user messages (MT 101 to MT 999) and system messages. A newly created message (when valid) gets queued when an operator invokes one of the commands to move or route the message onwards. If the operator uses the "Route" command, then the MPF invokes the services of the routing software to route the message onto the next queue. If the operator does not use the "Route" command, then the MPF itself moves the message directly into the queue selected by the operator. Since the message is routed immediately after the MPF completes its processing, there will never be more entries in this queue than the total number of operators entering messages). These entries, however, are barely observable when the queue is monitored, because the time span during which these messages are queued is very short. Acceptance criteria: Creator MPF must be mpc. Assigned MPF: mpc With the default routing rules, this MPF returns the following result: • Success: The message was successfully processed (created) and added onto the queue. By default, a SWIFT financial message producing this processing result is routed to the verification queue. SWIFT text messages are sent to _MP_authorisation. This MPF can also return the following results: • Failure • Discard • Invalid message. _MP_mod_emi_secu (Emission Security Modification) This is a queue for messages that require authentication or authorisation. A SWIFT or MX message is added to the Emission Security Modification queue if Alliance Access cannot authenticate it or authorise it. The messages in this queue are mostly input messages. Acceptance criteria: Creator MPF must be mpc. Assigned MPF: mpm 396 System Management Guide Appendix C - Queues and Message Processing Functions With the default routing rules, this MPF returns the following result: • Success: The message was successfully processed and is valid. This MPF can also return the following results: • Failure • Discard • Invalid message. _MP_mod_rec_secu (Reception Security Modification) This is a queue for output messages that require authentication. Alliance Access and SWIFTNet Link use the related security mechanisms to authenticate and authorise output messages. The output messages that Alliance Access and SWIFTNet Link cannot authenticate or authorise are first routed to this queue. If the message is being sent has failed PKI and digest authentication or the "authorisation to receive" checks, then it is routed to this queue. Then if the authentication, and authorisation are successful, the messages are routed according to the routing rules. If unsuccessful, the messages remain in the queue. Acceptance criteria: Message instance must be an output message and must be an original instance. Assigned MPF: mpm This MPF can return the following results: • Success • Failure • Discard • Invalid message. _MP_mod_reception (Modify After Reception) This queue is for output SWIFT messages. Acceptance criteria: Message instance must be an output message and must be an original instance. Assigned MPF: mpm This MPF can return the following results: • Success • Failure • Discard • Invalid message. _MP_mod_text (Text Modification) This is a queue for messages that have failed message validation, or messages that need data modification (only special fields cannot be modified, for example, sender). A SWIFT or MX 15 July 2011 397 Alliance Access 7.0.20 message is added to the Text Modification queue, in most cases, if any of the following conditions apply: • If one or more errors exist in the construction, or syntax of a message, making it syntactically incorrect as far as Alliance Access is concerned • If an error in the content of a message (for example, an incorrect amount) was identified during verification or authorisation • If a SWIFT message has been NAK'd by SWIFT due to the message being sent to an unknown address. Note that any SWIFT message sent to an unknown address is NAK'd by SWIFT. The NAK'd message is added to the Text Modification queue, not the Transmission Modification queue. Acceptance criteria: Message instance cannot be a notification. Assigned MPF: mpm With the default routing rules, this MPF returns the following result: • Success: The message was successfully processed and is valid. This MPF can also return the following results: • Failure • Discard • Invalid message. _MP_mod_transmis (Transmission Modification) A SWIFT message is added to this queue if the integrated application address specified for the receiver of a message is not valid. Acceptance criteria: Message instance cannot be a notification. Assigned MPF: mpm With the default routing rules, this MPF returns the following result: • Success: The message was successfully processed and is valid. This MPF can also return the following results: • Failure • Discard • Invalid message. _MP_recovery In the event of a FIN cold start, all completed messages that are not yet identified as delivered are re-activated and routed to this queue. Acceptance criteria: Message instance cannot be a notification. Assigned MPF: mpa This MPF can return the following results: • Success: The message was successfully processed (verified) and is valid. 398 System Management Guide Appendix C - Queues and Message Processing Functions By default, a message producing this processing result is routed to the authorisation queue (MP_authorisation). • Failure. _MP_verification The queue of messages awaiting verification consists of: • FIN messages created by an operator through the Message Creation application, or messages manually corrected through the Message Modification application (including those marked by SWIFT) and following the default message flow • SWIFT messages in CAS format received from the Application Interface when the disposition state requested by the CAS protocol specifies "Verify" or when routing point "MP_verification" is requested • SWIFT messages received from the Application Interface, if the message partner does not have the permission to bypass verification. Acceptance criteria: Message instance must be an input message and must be an original instance. Assigned MPF: mpa This MPF can return the following results: • Success: The message was successfully processed (verified) and is valid. By default, a message producing this processing result is routed to the authorisation queue (MP_authorisation). • Failure. _SI_delivery_subset (Delivery Subset Queue) This queue is assigned to an MPF process which updates the definitions of current SWIFT delivery subsets and the status of future subsets. The messages routed to this queue are notifications related to incoming MT 015, MT 055, and MT 067 messages. The system routing table associated with the SWIFT inbound routing point (_SI_from_SWIFT) creates these messages. The notifications are completed after being processed. The following entries can be found in the queue: • Notification related to an incoming MT 067. This response to an MT 047 redefines current subsets. • Notification related to an incoming MT 055. This response to an MT 035 redefines current subsets. • Notification related to an incoming MT 015 - Delayed NAK. SWIFT cancelled the MT 047 request due to an invalid definition of subset criteria. The notification updates the status of future subsets. • Notification related to an outgoing MT 047. This notification updates the status of future subsets. Acceptance criteria: Message format must be SWIFT Assigned MPF: _SI_delivery_subset 15 July 2011 399 Alliance Access 7.0.20 This MPF can return the following results: • Success • Failure. _SI_from_SWIFT (SWIFT Inbound Queue) This is the transient queue through which all MT messages received from SWIFT are routed to various routing points and exit queues. An incoming SWIFT MT message gets queued on its arrival in the system, and then routed immediately after the MPF completes its processing. Consequently, there is never more than one entry in the queue at any given point in time. This entry, however, is barely observable when the queue is monitored because the time span during which the message is queued is very short. Thus, in practice, the message count of this queue always reads "0". Acceptance criteria: Creator mpf must be _SI_from_SWIFT. Assigned MPF: _SI_from_SWIFT With the default routing rules, this MPF can return the following results: • Authorisation not present: No authorisation record was found. By default, an incoming message producing either of these processing results is routed to the re-authentication queue (_MP_mod_rec_secu). • FINCopy service Bypassed: When a Central Institution maintaining a FINCopy service has a problem, one of the fallback options for the Central Institution is to ask SWIFT to set the service into bypass mode. For more information, see "FINCopy service Fallback" in the FINCopy Service Description. In such a case, the PAC trailers contain no value. It is this criteria that is caught by the routing when you select the result FINCopy service Bypassed. • Failure: The incoming message failed authentication, using all three receive keys. By default, an incoming message producing this processing result is routed to the reauthentication queue (_MP_mod_rec_secu). • Invalid Certificate Policy ID: By default, an incoming message producing this processing result is routed to the reauthentication queue (_MP_mod_rec_secu). • Invalid digest: By default, an incoming message producing this processing result is routed to the reauthentication queue (_MP_mod_rec_secu). • Invalid Sign DN: By default, an incoming message producing this processing result is routed to the reauthentication queue (_MP_mod_rec_secu). • Not Authorised by RMA: A valid enabled authorisation was found, but the message was not permitted. By default, an incoming message producing this processing result is routed to the reauthentication queue (_MP_mod_rec_secu). 400 System Management Guide Appendix C - Queues and Message Processing Functions • Signature Auth. failure: The signature verification failed, this result can be applicable to the MAC equivalent or PAC equivalent signature. By default, an incoming message producing this processing result is routed to the reauthentication queue (_MP_mod_rec_secu). • Success: The incoming message passed checksum validation and authentication successfully. By default, a message producing this processing result is routed, according to its message type, to one of the following three exit queues: – the statement queue (Statement) – the system inbound queue (System) – the message inbound queue (Received). _SI_from_SWIFTNet (SWIFTNet Reception Queue) This is the transient queue through which all InterAct or FileAct messages received from SWIFTNet are routed to various routing points and exit queues. An incoming MX message gets queued on its arrival in the system, and then routed immediately after the MPF completes its processing. Consequently, the queue does not contain more than one entry at any given point in time. However, this entry is barely observable when the queue is monitored because the time span during which the message is queued is very short. Thus, in practice, the message count of this queue always reads "0". Acceptance criteria: Creator mpf must be _SI_from_SWIFTNet. Assigned MPF: _SI_from_SWIFTNet This MPF can return the following results: • Success: message is routed to the MXReceived queue • Failure: message is routed to the MXToBeInvestigated queue • Authorisation does not allow message • Authorisation not enabled • Authorisation not in validity period • No authorisation • Signature verification failure. By default, an incoming message that produces one of these processing results is routed to the re-authentication queue (_MP_mod_rec_secu). _SI_system_msg (System Outbound Queue) This is a transient queue for the APC and FIN system message (for example, MT 047 redefine delivery subsets) created using the SWIFT Interface application (SIA). Since the messages are routed immediately to the SWIFT outbound queue (_SI_to_SWIFT) after the MPF completes its processing, there is never more than one entry in the queue at any given point in time. This entry, however, is barely observable when the queue is monitored because the time span during which the message is queued is very short. Thus, in practice, the message count of this queue always reads "0". 15 July 2011 401 Alliance Access 7.0.20 Acceptance criteria: Creator mpf must be _SI_system_msg. Assigned MPF: _SI_system_msg This MPF can return the following results: • Success: The message was added successfully onto the queue. By default, a message producing this processing result is routed to the SWIFT outbound queue (_SI_to_SWIFT). • Failure. _SS_alarm_creation (Alarm Queue) This is a queue through which alarm messages are created before being sent to the message receiver. Acceptance criteria: Creator mpf must be SS_alarm_creation. Assigned MPF: SS_alarm_creation With the default routing rules, this MPF returns the following result: • Success. The alarm message can be successfully routed to the message addressee. This MPF can also return the following result: • Failure. _TR_NOTIF (Traffic Reconciliation Notification) This queue is used for traffic reconciliation, for example, to match a message report to a message instance. The notification is created in the TR_NOTIF routing point. Acceptance criteria: Creator mpf must be TR_REC. Assigned MPF: TR_REC With the default routing rules, this MPF can return the following results: • Delivered • Not delivered • Delayed delivery. This MPF can also return the following result: • Not matched _TR_REC (Traffic Reconciliation Received) This queue contains all the network reports (MT 010, 011, 015 and 019) that must be matched to a message instance. Assigned MPF: TR_REC With the default routing rules, this MPF can return the following results: • Delivered • Not delivered • Not matched • Delayed delivery. 402 System Management Guide Appendix C - Queues and Message Processing Functions _Unroutable (Unroutable messages) This is a queue to manage messages that cannot be successfully routed to any other queue in the case of a message not matching the acceptance criteria of a queue. It is the responsibility of the user to investigate and define what next to do with this message. Assigned MPF: Dummy_mpfn This MPF can return the following results: • Success • Failure. C.2 List of Exit Queues AI_to_APPLI All exit queues, except _SI_to_SWIFT,_SI_to_SWIFTNet are processed by a single Message Processing Function, identified as AI_to_APPLI. The processing results returned by this MPF are the same for all exit queues and are therefore described only once in this section. The two possible processing results are: • Success: The message has been delivered successfully to the message partner. By default, a message producing this processing result is completed. • Failure: The MPF is unable to reconstruct the message correctly. Such a problem may occur, for example, when the version number of the Message Syntax Table assigned to the LT through which a SWIFT message was received (and accepted because minimum validation was applied) is incorrect. By default, a message producing this processing result is routed to the follow-up queue (ToBeInvestigated). BatchMXAcks This is the queue of ACK notifications related to outgoing MX messages created by message partners and entered into Alliance Access through the Application Interface. The AI input session uses the File Transfer connection method. These notifications are created at the SWIFTNet outbound routing point and routed to this exit queue when the message is ACK'd. The reception of a positive acknowledgement causes the MPF associated with the SWIFT outbound queue (_SI_to_SWIFTNet) to return a processing result equal to "Success". BatchMXRejects This is the queue of NAK notifications related to outgoing MX messages created by message partners and entered into Alliance Access through the Application Interface. The AI input session uses the File Transfer connection method. These notifications are created at the SWIFT outbound routing point and routed to this exit queue when the message is NAK'd. The reception of a negative acknowledgement causes the MPF associated with the SWIFT outbound queue (_SI_to_SWIFTNet) to return a processing result equal to "Failure". 15 July 2011 403 Alliance Access 7.0.20 BatchSwiftAcks (Batch Ack Queue) This is the queue of SWIFT ACK notifications related to outgoing messages created by message partners and entered into Alliance Access through the Application Interface. The AI input session uses the File Transfer connection method, for example, batch transfer of messages using a DOS or UNIX file. These notifications are created at the SWIFT outbound routing point and routed to this exit queue when the message is ACK'd by APC/FIN. The reception of a positive acknowledgement causes the MPF associated with the SWIFT outbound queue (_SI_to_SWIFT) to return a processing result equal to "Success". BatchSwiftNaks (Batch Nack Queue) This is the queue of SWIFT NAK notifications related to outgoing messages created by message partners and entered into Alliance Access through the Application Interface. The AI input session uses the File Transfer connection method, for example, batch transfer of messages using a DOS or UNIX file. These notifications are created at the SWIFT outbound routing point and routed to this exit queue when the message is NAK'd by APC or FIN. The reception of a negative acknowledgement causes the MPF associated with the SWIFT outbound queue (_SI_to_SWIFT) to return a processing result equal to "NAK'd". DeliveryNotifAcks The following traffic reconciliation notification instances are routed from the _TR_NOTIF routing point to this queue: • DeliveryNotifAcks. MT 011 notifications. The MPF at this routing point is AI_to_APPLI. From this exit point, you can send delivery notification instances to a message partner with Connection Method Print or to a message partner with Data Format CAS2, MQ-MT or XML version 2. For more information about the configuration parameter that affects this queue, see "Traffic Recon " on page 169. DeliveryNotifNaks The following traffic reconciliation notification instances are routed from the _TR_NOTIF routing point to this queue: • DeliveryNotifNaks. MT 010, MT 015, and MT 019 notifications. The MPF at this routing point is AI_to_APPLI. From this exit point, you can send delivery notification instances to a message partner with Connection Method Print or to a message partner with Data Format CAS2, MQ-MT or XML version 2. For more information about the configuration parameter that affects this queue, see "Traffic Recon " on page 169. 404 System Management Guide Appendix C - Queues and Message Processing Functions FileActAcks This is the queue of ACK notifications related to outgoing FileAct messages created by message partners and entered into Alliance Access through the Application Interface. The AI input session uses the File Transfer connection method. These notifications are created at the SWIFTNet outbound routing point and routed to this exit queue when the message is ACK'd. The reception of a positive acknowledgement causes the MPF associated with the SWIFT outbound queue (_SI_to_SWIFTNet) to return a processing result equal to "Success". FileActReceived This is the exit queue to which all incoming FileAct messages received from SWIFTNet are routed with success from the SWIFTNet inbound routing point. FileActReject This is the queue of NAK notifications related to outgoing FileAct messages created by message partners and entered into Alliance Access through the Application Interface. The AI input session uses the File Transfer connection method. These notifications are created at the SWIFT outbound routing point and routed to this exit queue when the message is NAK'd. The reception of a negative acknowledgement causes the MPF associated with the SWIFT outbound queue (_SI_to_SWIFTNet) to return a processing result equal to "Failure". FileDeliveryNotifAck The following traffic reconciliation notification instances are routed from the _TR_NOTIF routing point to this queue: • FileDeliveryNotifAck. Positive FileAct delivery notifications. The MPF at this routing point is AI_to_APPLI. From this exit point, you can send the delivery notification instances to a message partner with connection method printer or File Transfer XML. FileDeliveryNotifNak The following traffic reconciliation notification instances are routed from the _TR_NOTIF routing point to this queue: • FileDeliveryNotifNak. Negative FileAct delivery notifications. The MPF at this routing point is AI_to_APPLI. From this exit point, you can send the delivery notification instances to a message partner with connection method printer or File Transfer XML. LocalMXAcks This is the queue of ACK notifications related to outgoing MX messages generated by Alliance Access or outgoing MX user-to-user messages created manually through Alliance Messenger (available on Alliance Web Platform). The notifications are created at the SWIFTNet outbound routing point and routed to this exit queue when the message is ACK'd. The reception of a positive acknowledgement causes the MPF associated with the SWIFTNet outbound queue (_SI_to_SWIFTNet) to return a processing result equal to "Success". 15 July 2011 405 Alliance Access 7.0.20 LocalMXRejects This is the queue of NAK notifications related to outgoing MX messages generated by Alliance Access or outgoing MX user-to-user messages created manually through Alliance Messenger (available on Alliance Web Platform). The notifications are created at the SWIFTNet outbound routing point and routed to this exit queue when the message is NAK'd. The reception of a negative acknowledgement causes the MPF associated with the SWIFTNet outbound queue (_SI_to_SWIFTNet) to return a processing result equal to "Failure". LocalSwiftAcks (Local Ack Queue) This is the queue of SWIFT ACK notifications related to outgoing messages generated by Alliance Access or outgoing FIN user-to-user messages created manually through the Message Preparation component of Alliance Access. The messages are: • MT 047: Delivery Instructions Redefinition Request • MT 090: User-to-SWIFT message • MT 0nn: All system messages • MT 101 through MT 999: FIN messages created manually through the Message Preparation component. The notifications are created at the SWIFT outbound routing point and routed to this exit queue when the message is ACK'd by APC/FIN. The reception of a positive acknowledgement causes the MPF associated with the SWIFT outbound queue (_SI_to_SWIFT) to return a processing result equal to "Success". LocalSwiftNaks (Local Nack Queue) This is the queue of SWIFT NAK notifications related to outgoing messages generated by Alliance Access or outgoing FIN user-to-user messages created manually through the Message Preparation component of Alliance Access. These messages are described above. The notifications are created at the SWIFT outbound routing point and routed to this exit queue when the message is NAK'd by APC/FIN. The reception of a negative acknowledgement causes the MPF associated with the SWIFT outbound queue (_SI_to_SWIFT) to return a processing result equal to "NAK'd". MXDeliveryNotifAcks The following traffic reconciliation notification instances are routed from the _TR_NOTIF routing point to this queue: • MXDeliveryNotifAcks. MX notifications. The MPF at this routing point is _AI_to_APPLI. From this exit point, you can send the delivery notification instances to a message partner with connection method printer or File Transfer XML. 406 System Management Guide Appendix C - Queues and Message Processing Functions MXDeliveryNotifNaks The following traffic reconciliation notification instances are routed from the _TR_NOTIF routing point to this queue: • MXDeliveryNotifNaks. MX notifications. The MPF at this routing point is _AI_to_APPLI. From this exit point, you can send the delivery notification instances to a message partner with connection method printer or File Transfer XML. MXReceived This is the exit queue to which all incoming MX messages received from SWIFTNet are routed with success from the SWIFTNet inbound routing point. MXSystem This is the exit queue to which all incoming MX delivery notifications received from SWIFTNet are routed from the SWIFTNet inbound routing point. A copy is sent to _TR_REC for matching the notification with the original message instance. MXToBeInvestigated (follow-up queue) This is the default target queue specified for MX messages failing to match any of the conditional routing criteria specified in the sequence of routing rules at a routing point. Received (Message Inbound Queue) All incoming messages received from APC/FIN are routed to this exit queue from the SWIFT inbound routing point, except: • system messages (MT 0nn) • statement messages (MT 940, MT 950, MT 970, and MT 996) _SI_to_SWIFT (SWIFT Outbound Queue) This is the queue of SWIFT messages ready to be sent to the SWIFT network. It is sometimes referred to as the SWIFT "ready" queue. The queue contains, most of the time, messages created at several processing points in the system: • FIN messages in CAS format received from the Application Interface when the disposition state requested by the CAS protocol specifies "Ready" or when routing point _SI_to_SWIFT is requested. • FIN messages received from the Application Interface, if the message partner has the permissions to bypass verification and authorisation. • FIN messages entered into the system by the Application Interface and routed from the AI inbound queue by internal default routing. • APC and FIN System Messages created using the Message Creation application. • MT 047 message created by the Redefine Delivery command available in the SWIFT Interface application. The message is routed from the system outbound queue (_SI_system_msg) as well. • Messages created using the Message Creation application. In general, these messages are routed to the SWIFT outbound queue from the authorisation queue (MP_authorisation). 15 July 2011 407 Alliance Access 7.0.20 However, when the operator has the proper bypass permissions, messages may also be moved directly to the SWIFT outbound queue from any of the other queues involved in the preparation of messages, for example: – Message creation queue (MP_creation) – Verification queue (MP_ verification) – Modification queues (MP_mod_emi_secu, MP_mod_text, MP_mod_transmis). Acceptance criteria: Message instance must be an original input SWIFT message. Assigned MPF: _SI_to_SWIFT With the default routing rules, the processing results returned by this MPF are: • Success: The outgoing message was positively acknowledged by APC/FIN. By default, a message producing this processing result is completed and a notification is routed to one of the four ACK queues. • Nacked: The outgoing message was negatively acknowledged by APC/FIN. By default, a message producing this processing result is completed and a notification is routed to one of the four NAK queues. When created using the Message Creation application, the message is routed to the modification queue (MP_mod_text) instead. • Inactive correspondent: By default, a message producing this processing result is routed to the _MP_mod_transmis queue. Other processing results which can be returned by this MPF are: • Failure • Authorisation not present: No authorisation record was found. By default, an outgoing message producing this processing result is routed to the re-authentication queue (_MP_mod_emi_secu). • Not authorised by RMA: A valid enabled authorisation was found, but the message was not permitted. By default, an outgoing message producing this processing result is routed to the re-authentication queue (_MP_mod_emi_secu). • Failure: The processing of the outgoing message fails. By default, an outgoing message producing this processing result is routed to the follow-up queue (ToBeInvestigated). An outgoing message whose processing fails for one of the reasons mentioned above is routed by default to the follow-up queue (ToBeInvestigated). _SI_to_SWIFTNet (SWIFTNet Emission Queue) This is the queue which provides a collection point for InterAct or FileAct messages ready for emission. Acceptance criteria: Message instance must be a normal original input MX message. Assigned MPF: _SI_to_SWIFTNet With the default routing rules, the processing results returned by this MPF are: • "Success": The outgoing message was positively acknowledged. 408 System Management Guide Appendix C - Queues and Message Processing Functions By default, a message producing this processing result is completed and a notification is routed to the MX delivery ACK queues. • "Nacked": The outgoing message was negatively acknowledged. By default, a message producing this processing result is completed and a notification is routed to the MX delivery NAK queues. An outgoing message whose processing fails for one of the reasons mentioned above is routed by default to the follow-up queue (MXToBeInvestigated). Statement (Statement Queue) Incoming statement messages are routed to this exit queue from the SWIFT inbound routing point. The messages are: • MT 940: Customer Statement Message • MT 950: Statement Message • MT 970: Netting Statement • MT 996: Answer to an MT 995 Query System (System Inbound Queue) All incoming system messages are routed to this exit queue from the SWIFT inbound routing point except: • MT 021: FIN Retrieval However, a copy of each MT 021 FIN retrieval message is routed to the system inbound queue as well (System). ToBeInvestigated (Follow-up Queue) This is the default target queue specified for MT messages failing to match any of the conditional routing criteria specified in the sequence of routing rules at a routing point. The follow-up queue is also invoked when MPFs fail to process messages which are insufficiently validated or improperly routed. C.3 Printout of Default Queues Overview You can produce a printed document of all default queues and the routing rules associated with them from the Routing application. The content of the printed document may vary, depending on the licences present. For examples of default queues see the Default Printouts on the release media, or on www.swift.com, under Support > Documentation (User Handbook). 15 July 2011 409 Alliance Access 7.0.20 C.4 OI_to_OTHER Queue Description When a correspondent has been assigned the OTHER network, the operator may dispose the message to the _OI_to_OTHER queue (which is a user-defined queue). An operator chooses the network type in the Network tab in the Message Creation and Message Modification applications. The _OI_to_OTHER queue has the properties of a user-defined but an operator cannot delete it. Function assigned The RouteMsg function is applied to any messages in the _OI_to_OTHER queue. Note 410 An operator must add the queue, _OI_to_OTHER, as a valid target to every routing point that has rules which route messages to _OI_to_OTHER. System Management Guide Appendix D - Message Formats Used in AI Appendix D Message Formats Used in AI Introduction This section contains examples of the message formats that AI accepts when it processes messages using the various connection methods. Files must contain only ASCII text and at least Blocks 1, 2, and 4 of a SWIFT message. Blocks 3 and 5 are optional. Examples of Message Formats The Windows directory %alliance%\SWIFT\SERVER\MXS\batch_examples ($ALLIANCE/ Mxs/batch_exampleson UNIX) contains examples of message and parameter files for the following formats: • DOS-PCC (.dos files) • MERVA/2 (.mv2 files) • RJE (.rje files). The Windows directory %alliance%\MXS\xsd ($ALLIANCE/Mxs/xsd on UNIX) contains examples of message files for the following formats: • XML Format 1 (Samples_v1.tar.Z) • XML Format 2 (Samples_v2.tar.Z) D.1 PC Connect (DOS-PCC) D.1.1 Description of PC Connect (DOS-PCC) Format Overview Batch message files processed follow a standard format for both input, and output. The DOS message file is in ST200 PC Connect format. MAC/PAC values If a message to be transferred to the back-office application contains a MAC and/or PAC, then the MAC/PAC values are transferred in the MAC/PAC trailers in block 5. If there are no MAC/PAC values and if the option Always Transfer MAC/PAC has been set for the message partner, then a dummy value ("00000000") is transferred in the MAC/PAC trailers in block 5. PKI signatures If the Transfer PKI Signatures flag is set for the message partner, then the PKI signature is transferred in a new trailer in block S, identified by the SIG: identifier. It contains the complete Signature element (as provided by SWIFTNet Link) that is relevant to the message, as follows: {S:{SIG:<SwSec:Signature>... </SwSec:Signature >}} The SIG trailer is the last trailer in the block S. 15 July 2011 411 Alliance Access 7.0.20 If both the PKI signature replacing the MAC, and PAC1 if present, (MAC-equivalent signature) and the PKI signature replacing the PAC2 (PAC2-equivalent signature) are present, then the PAC2-equivalent is appended to the MAC-equivalent signature in one SIG trailer. Note Back-office applications must be ready to receive and store PKI signatures. Signature result If the message to be transferred to the back-office application is MAC-equivalent PKI-signed, then the verification result is passed with the message in block S. D.1.2 Batch Input and Output in DOS-PCC Format Constraints The format for input and output files is identical. The following constraints apply: • The disk that stores the message files must be formatted and write enabled (in the case of Batch Output). • Each message within a file starts with "01" hex and ends with "03" hex. Space between the end of the message and the end of a sector (512 bytes), are filled with the hex character "20" or null "00". • Each message starts on a sector boundary and may take up more than one sector. • All messages must be in 8-bit ASCII. Examples of Message Formats You can find examples of the DOS-PCC message format in files with the .dos extension in the following directory: • Windows: %alliance%\SWIFT\SERVER\MXS\batch_examples • UNIX: $ALLIANCE/Mxs/batch_examples Example The following example is provided in both hexadecimal and ASCII so that the details are clear. 412 System Management Guide Appendix D - Message Formats Used in AI DOS-PCC Input Message Format DOS-PCC Input and Output Message Format 15 July 2011 413 Alliance Access 7.0.20 D.2 RJE D.2.1 Description of RJE Format Overview Message files processed through the RJE connection method follow a standard format for both input, and output. The RJE message file is in ST200 RJE format. Alliance Access accepts "real" ST200 RJE format messages without any modification required to the existing format. Alliance Access handles the following: • Stripping ST200 non-essential header and trailer information • Ignoring empty messages (messages beginning and ending with $$) • Synonym notations for CRLF (such as EM ITB, EM ETB, \n, nl, Cr, Lf) • Stripping non-'X' character sets 414 System Management Guide Appendix D - Message Formats Used in AI MAC/PAC values If a message to be transferred to the back-office application contains a MAC and/or PAC, then the MAC/PAC values are transferred in the MAC/PAC trailers in block 5. If there are no MAC/PAC values, and if the field Always Transfer MAC/PAC has been set for the message partner, then a dummy value ("00000000") is transferred in the MAC/PAC trailers in block 5. PKI signatures If the Transfer PKI Signatures flag is set for the message partner, then the PKI signature is transferred in a new trailer in block S, identified by the SIG: identifier. It contains the complete Signature element (as provided by SWIFTNet Link) that is relevant to the message, as follows: {S:{SIG:<SwSec:Signature>... </SwSec:Signature >}} The SIG: trailer is the last trailer in block S. If both the PKI signature replacing the MAC [+PAC1 if present] (MAC-equivalent signature) and the PKI signature replacing the PAC2 (PAC2-equivalent signature) are present, then the PAC2equivalent is appended to the MAC-equivalent signature in one SIG trailer. Note Back-office applications must be ready to receive and store PKI signatures. Signature result If the message to be transferred to the back-office application is MAC-equivalent PKI-signed, then the verification result is passed with the message in block S. D.2.2 Batch Input and Output Examples of Message Formats You can find examples of the RJE message format in files with the .rje extension in the following directory: • Windows: %alliance%\SWIFT\SERVER\MXS\batch_examples • UNIX: $ALLIANCE/Mxs/batch_examples Overview Each message within an RJE message file is delimited using the "$" character. The format for input and output files is identical, although input messages do not generally contain the MAC trailer. The following example shows a batch output file containing two messages. All messages must be in 8-bit ASCII. The following example is printed in both hexadecimal and ACSCII so that the details are clear. 15 July 2011 415 Alliance Access 7.0.20 RJE Message Format: Input Format Note The input sequence number of the RJE message in block 1 is overwritten by Alliance when the message is passed on to the SWIFT network. RJE Message Format: Output Format 416 System Management Guide Appendix D - Message Formats Used in AI D.3 MERVA/2 Format MAC/PAC values If a message to be transferred to the back-office application contains a MAC and/or PAC, then the MAC/PAC values are transferred in the MAC/PAC trailers in block 5. If there are no MAC/PAC values, and if the option Always Transfer MAC/PAC has been set for the message partner, then a dummy value ("'00000000") is transferred in the MAC/PAC trailers in block 5. PKI signatures If the Transfer PKI Signatures option is set for the message partner, then the PKI signature is transferred in a new trailer in block S, identified by the SIG: identifier. It contains the complete Signature element (as provided by SWIFTNet Link) that is relevant to the message, as follows: {S:{SIG:<SwSec:Signature>... </SwSec:Signature >}} The SIG: trailer is the last trailer in the block S. If both the PKI signature that is replacing the MAC, and PAC1 if present, (MAC-equivalent signature) and the PKI signature that is replacing the PAC2 (PAC2-equivalent signature) are present, then the PAC2-equivalent is appended to the MAC-equivalent signature in one SIG trailer. Note Back-office applications must be ready to receive and store PKI signatures. Signature result The verification result is not passed with the message in the block S. Example Each message in a file starts with a 4-byte count of the message length in hexadecimal. Here is an example of part of a SWIFT input message file: MERVA/2 Format Note 15 July 2011 For notification instances, no Unique File Transfer Reference is included. 417 Alliance Access 7.0.20 Examples of Message Formats You can find examples of the MERVA/2 message format in files with the .mv2 extension in the following directory: • Windows: %alliance%\SWIFT\SERVER\MXS\batch_examples • UNIX: $ALLIANCE/Mxs/batch_examples D.4 Common Application Server (CAS) Format Overview This section shows examples of messages accepted by Application Interface when processed using the Common Application Server (CAS) protocol. Alliance Access supports CAS protocol standards 1 and 2. Note The CAS1 data format does not allow transmission of any authentication results. PKI signatures are not transmitted. In the Application Interface, two connection methods currently support Common Application Server (CAS): • File Transfer (CAS). File Transfer using the CAS message format permits you to send and receive batch message files in either Network Dependent Format (NDF) or the Network Independent Format (NIF). • Interactive. Interactive permits you to send and receive individual messages either Network Dependent Format (NDF) or the Network Independent Format (NIF). D.4.1 The Common Application Server (CAS) Protocol Overview As part of the Application Interface, Alliance Access supports CAS protocol standards 1 and 2. The Interactive and the File Transfer connection methods are used to transfer messages of a specified format between Alliance Access and a message partner. This transfer is carried out according to Common Application Server (CAS) standards. Both CAS protocols provide a common form of access between SWIFT terminal products (CBTs) and back-office mainframe applications. In addition to this, using the CAS protocol permits Alliance Access to store messages received from networks other than SWIFT. Messages received using the CAS protocol, may be formatted according to either the Network Dependent Format (NDF) or the Network Independent Format (NIF). Network Dependent Format (NDF) This format matches the SWIFT network. Using the NDF format, financial institutions currently communicating with ST400 systems can re-use much of their CAS application software when switching to Alliance Access. Network Independent Format (NIF) With this format, the body of the message is limited to the financial data, that is, block 4 of the SWIFT message format. The network-related information is in a network independent format. 418 System Management Guide Appendix D - Message Formats Used in AI Using the NIF syntax enables financial institutions to use Alliance Access to exchange and process messages which are coming from SWIFT or non-SWIFT networks, for example, CHIPS, CHAPS, Fedwire, SIC, and so on. Network Format Network NDF NIF SWIFT Application Service Profile Application Service Profile UNIX only: Sic - User Format Services (UFS) UNIX only: Other networks - User Format Services (UFS) CAS Message Encoding/Decoding The NDF and NIF formats are defined using the ISO standard Abstract Syntax Notation 1 (ASN. 1). Its companion, the Basic Encoding Rules (BER) Standard defines how data described using ASN.1 can be exchanged using a common transfer syntax. The messages exchanged between Alliance Access and message partners are encoded to the common transfer syntax for transmission, and from the common transfer syntax on reception. In addition to the ASN.1 notation used by both CAS 1 and CAS 2 standards, the CAS 2 standard also supports the notation, Text Encoding. This notation has been developed to simplify the implementation of the CAS protocol. The structure and parameters of the CAS protocol remain unchanged, but the text encoding method uses special text characters to delimit the start and end of each structure block and field within the message. D.4.2 CAS Format Example The following is an example of a SWIFT input message in CAS format, with the Processing Data Units (PDUs) non-encoded Note 15 July 2011 The example shows only the more commonly used fields. It does not contain all possible PDU fields available to the protocol. 419 Alliance Access 7.0.20 D.4.3 CAS Message with ASN.1 Encoding Example The following example is a CAS message in network-dependent format (NDF), with ASN.1 encoding. 420 System Management Guide Appendix D - Message Formats Used in AI D.4.4 CAS2 Message with ASN.1 Encoding PKI signatures If the Transfer PKI Signatures option is selected in the message partner profile, then the PKI signature is transferred in a new field sigValue. It contains the complete Signature element (as provided by SWIFTNet Link) that is relevant to the message. The sigValue field has a maximum size of 5000 bytes. Tag ID 21 is created in MXAMessage.messageLPI for this purpose. If both a MAC-equivalent signature and a PAC2-equivalent signature are present, then the PAC2-equivalent is appended to the MAC-equivalent signature in the sigValue field. Note Back-office applications must be ready to receive and store PKI signatures. MAC/PAC values If the Always Transfer MAC/PAC option has been selected for the message partner profile, and the message contains no MAC/PAC values, then dummy MAC/PAC trailers are added to 15 July 2011 421 Alliance Access 7.0.20 the MT message and sent to the back-office application. The value of these dummy MAC and PAC trailers is 00000000. Signature result The MAC-equivalent signature verification result is passed by means of the field authResult. The PAC-equivalent signature verification result is passed by means of the field pacResult. For dual-signed messages of type MT 096, the signature verification result of the PKI signatures will be passed in the existing pacResult tag. The verification result has one of the following values: • successCurrent • bypassed • failed D.4.5 CAS Message with Text Encoding Example The following example is a CAS message in network-dependent format (NDF), with text encoding. 422 System Management Guide Appendix D - Message Formats Used in AI 15 July 2011 423 Alliance Access 7.0.20 D.4.6 CAS2 Message with Text Encoding PKI signature If the Transfer PKI Signatures option is selected in the message partner profile, then the PKI signature is transferred in a new field SIGV. This field contains the complete Signature element (as provided by SWIFTNet Link) that is relevant to the message. The SIGV field is created in MXAMessage.MLPI and has a maximum of 5000 bytes. If both a MAC-equivalent signature and a PAC2-equivalent signature are present, then the PAC2-equivalent signature is appended to the MAC-equivalent signature in the SIGV field. Note Back-office applications must be ready to receive and store PKI signatures. MAC/PAC trailers If the Always Transfer MAC/PAC option is not selected in the message partner profile, then MAC/PAC trailers are not added to the MT message and are not sent to the back-office application. If the Always Transfer MAC/PAC option has been selected for the message partner profile, then dummy MAC/PAC trailers are added to the MT message and sent to the back-office application. The value of these dummy MAC and PAC trailers is 00000000. Signature result The MAC-equivalent signature verification result is passed in the existing field AUTR. The PAC-equivalent signature verification result is passed in the existing field PACR. For dual-signed messages of type MT 096, the signature verification result of the PKI signatures will be passed in the existing PACR tag. 424 System Management Guide Appendix D - Message Formats Used in AI The verification result has one of the following values: • successCurrent • bypassed • failed D.5 XML Formats Introduction The XML formats are used for the processing of MX messages. D.5.1 XML Format 1 Introduction The following sections describe the format of the Protocol Data Units (PDUs) exchanged between Alliance Access and the application. Examples of Message Formats You can find examples of the XML version 1 message format in files Samples_v1.tar.Z in the following directory: • Windows: %alliance%\SWIFT\SERVER\MXS\batch_examples • UNIX: $ALLIANCE/Mxs/batch_examples D.5.1.1 XML Data Format Description D.5.1.1.1 Protocol Data Units Description The application and Alliance Access exchange PDUs that are sequences of bytes with the following structure: Prefix Length Signature DataPDU • Prefix (1 byte): the character 0x1e • Length (6 bytes): length (in bytes) of the Signature and DataPDU fields. This length is base-10 encoded as six ASCII characters, and is left-padded with zeros, if needed. • Signature (24 bytes) : signature computed on the DataPDU using the HMAC-SHA256 algorithm: the first 128 bits are base-64 encoded. This signature authenticates the originator of the DataPDU (the application or Alliance Access) and guarantees the integrity of the DataPDU. This action is referred to as local authentication (LAU). If Alliance Access is configured to not require LAU, then the field must contain NULL characters. • DataPDU: XML structure containing the information relevant to be processed (message or report) encoded in UTF-8. The first byte of this field must be the character < -(0x3C). A byteorder marker is not supported. 15 July 2011 425 Alliance Access 7.0.20 The structure of the DataPDU is described in the rest of this section. Each document has a structure defined as: <?xml version="1.0" encoding="utf-8"?><Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01"> ... </Saa:DataPDU> A DataPDU field that Alliance Access send to the application may contain structured data that is received from SWIFTNet, Therefore, the field may contain the following additional namespace declarations: xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt". xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec" <?xml version="1.0" encoding="utf-8"?> The signature is computed on the complete DataPDU field, that includes the string <?xml version="1.0" encoding="utf-8"?>. The XML representation must not be altered between the signature computation and the verification. A batch file can contain one or more consecutive PDUs. D.5.1.1.2 Alliance Access WebSphere MQ Interface XML format supported The Alliance Access WebSphere MQ Interface (MQSA) also supports the XML format. However, it only uses the DataPDU structure. The Prefix, Length, and Signature are not supported by MQSA 7.0. When instructed by the application that sends the message, MQSA has to send back a reply to that application, indicating whether the message was accepted or rejected by Alliance Access. MQSA uses the LogicalReply element for this. D.5.1.1.3 Structure of the DataPDU Conventions used This section describes the various XML elements that can be present in the DataPDU field. The description uses a table format, and the elements are ordered top-down. The corresponding schema is located in the following directory in the Alliance Access release tree: \MXS\xsd\SAA_XML_v1_0.xsd /MXS/xsd/SAA_XML_v1_0.xsd In the following tables, the columns From and To indicate whether the element is mandatory (M), optional (O) or not applicable (--) for the corresponding direction of a message or report exchange. The directions are defined as follows: • From: from the application to Alliance Access • To: from Alliance Access to the application DataPDU Element Description Type From To SenderReference Contains the UUMID of the message. String(1..50) -- O 426 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To Not present if LogicalReply is present. ( Message | The Message. Message M M Report | The Report. Report -- M LogicalReply ) LogicalReply sent to MQSA. LogicalReply -- M Element Description Type From To MessageFormat The message format. String M M String M M Message Possible values are: • MX MessageSubFormat The message sub-format. Possible values are: • Input • Output From: only Input is allowed. Sender The address of the message sender message sender (see "AddressFullName"). The first 8 characters of the X1 member must match the institution of the RequestorDN (case insensitive, see "SWIFTNetRequestAttribute"). AddressFullName M M Receiver The address of the message receiver (see Address). Address M M LiveMessage Is it a live message or is it a test message?: Boolean -- M String M M • true: message is Live • false: test message (pilot) MessageNature The message nature. Possible values are: • FinancialNature • TextNature • NetworkNature • SecurityNature • ServiceNature 15 July 2011 427 Alliance Access 7.0.20 Element Description Type From To For MX messages, the value FinancialNature must be used. MessageLPI The Local Processing information. MessageLPI M M MessageTPI The Transmission information. MessageTPI M M MessageSRI The Sender-to-Receiver information. MessageSRI M M MessageText Contains the message text, that is, the Application Header(1) (if required) and the Business Document. Both are described in the documentation of the Solutions. Any M M (1) If an Application Header is required, then the schema of the Application Header for each message that is part of a Solution is listed in the Implementor section of the Standards Handbook for that specific Solution. MessageLPI Element Description Type From To OriginalMessage The Alliance Access instance type: Boolean -- O Boolean O -- • true: Original instance • false: Copy instance ModifyAllowed If set to true, then the message can be modified using the Message Modification application in Alliance Messenger(1) (available on Alliance Web Platform). If set to false, then the message cannot be changed. Default value: • as defined in the Message Partner configuration • true for MQSA DeleteInhibited If set to true, then only its creator can delete the message, if it is still in the creation queue. Default value: false Boolean O -- MinValidation Requested message validation level. String O -- Possible values are: • None • Minimum Extract routing keywords from message text • Intermediate (same as minimum) • Maximum (same as minimum) 428 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To If specified, has precedence over the Alliance Access configuration. CBTPriority The Alliance Access message priority. If not present, then it is determined by the field NetworkPriority (see "MessageTPI"). Integer(0..9) O -- DispositionState The requested message disposition state. The corresponding routing point name is listed between parentheses. String O -- Possible values are: • Verify (_MP_verification) • (_Authorise_MP_authorisation) • Modify (_MP_mod_text) • Ready based on the preferred network settings of the Receiver in the Alliance Access Correspondent Information File Taken into account if TargetApplicationRule (see "TargetApplication") is "CBTApplication". Not applicable to MQSA. NetworkAttribute Set of network-related attributes. NetworkAttribute M M SecurityAttribute Set of security-related attributes. SecurityAttribute O O FormatAttribute Set of format-related attributes. Not currently used. FormatAttribute O O TargetApplication Specifies where the message has to be created in Alliance Access. If specified, has precedence over the Alliance Access Message Partner configuration. Not applicable to MQSA. TargetApplication O -- MessageOrigin The Alliance Access component that created the message. See "MessageOrigin". MessageOrigin -- O CBTRoutingInfo The routing point the message instance was located on before emission to the application. String(1..20) -- O MANRoutingCode Information to influence the routing in Alliance Access. The code entered here is visible through the routing keyword "Routing_code". String(1..6) O O 15 July 2011 429 Alliance Access 7.0.20 Element Description Type DuplEmission Indicates whether Alliance Access already Boolean attempted to send this message instance to the application. From To -- O (1) The Alliance Workstation Message Modification application does not support editing MX messages. NetworkAttribute Element Description Type From To SWIFTNetRequestAttribute SWIFTNet request attributes. SWIFTNetRequest Attribute M M SWIFTNetResponseAttribu te SWIFTNetResponse Attribute -- O SWIFTNet response network attributes. SWIFTNetRequestAttribute For Standards MX messages, the PKI signature, if present, is transferred using the SWIFTNetRequestAttribute:AuthValue elements. The PKI signature verification result is passed in the SWIFTNetRequestAttribute:AuthResult elements. Element Description Type From To RequestorDN The requestor DN. String(1..100) M M ResponderDN The responder DN. String(1..100) M M Service The SWIFTNet service name. String(1..30) M M RequestType The identification of the message (that is, the Message Identifier) String(1..30) M O For an MX message, the format is: <bus. area>.<msg type>.<variant>.<version> For example, ifds.001.001.01 It corresponds to the namespace of the URI of the XML Document in the MessageText which has following structure: urn-prefix:[[service name]$]Message Identifier NRIndicator Indicates whether non-repudiation requested. Default value: as defined in the Alliance Access emission profile configuration Boolean O -- NonRepType Non-repudiation processing information (Type). String -- O String -- O Possible Values are: • SvcOpt • SvcMand NonRepWarning 430 Non-repudiation processing information (Warning) System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To SwiftRef The reference generated by the central SWIFT infrastructure. Always present for output messages, Transmission Reports with NetworkDeliveryStatus NetworkAcked and Delivery Reports. String -- O String -- O Format: SWITCHid-YYYY-MMDDTHH:MM:SS.procid.digitsZ Where: • SWITCHid is the ID of the switch that generated the reference • procid is the process ID of the process that created the reference • digits makes the reference unique within a given second. The timestamp is the time of generation of the reference in UTC. SwiftRequestRef The reference generated by the emitting SWIFTNet Link. Always present for output messages, Transmission Reports with NetworkDeliveryStatus NetworkAcked and Delivery Reports. SNLid-YYYY-MMDDTHH:MM:SS.procid.digitsZ Where SNLid is the ID of the SWIFTNet Link that generated the reference. The other parts are identical to the format of SwiftRef. CBTReference The reference generated by the Alliance Access (for messages sent) or by the correspondent application (for messages received). String -- O SNLEndPoint The SWIFTNet Link endpoint. Real-time messages only. String -- O SnFQueueName The store-and-forward queue name. String -- O SnFInputTime SWIFTNet storage location and time of a store-and-forward request (UTC). String -- O Format: nnnn:YYYY-MM-DDTHH:MM:SS Where nnnn is the SWIFT internal storage identifier. SnFPDMHistory Duplication history details. Output messages only. Any (1) -- O ValidationDescriptor MVal processing result. Any (2) -- O AuthResult The authentication result. String -- O 15 July 2011 431 Alliance Access 7.0.20 Element Description Type From To Any (2) -- O Possible values are: • Success • Bypassed • Failed AuthValue The authentication value. (1) For previous delivery attempts, this SWIFTNet specific data element provides the delivery attempt history. See "Additional Information" for a description of this structure. (2) These fields contain SWIFTNet data elements that are provided for purposes of completeness. Further processing of these elements is not required. SWIFTNetResponseAttribute Element Description Type From To ResponderDN The responder DN. String -- O NonRepType Non-repudiation processing information (Type). String -- O Possible Values are: • SvcOpt • SvcMand Real-time messages only. NonRepWarning Non-repudiation processing information (Warning) Real-time messages only. String -- O ResponseRef The reference generated by the central SWIFT infrastructure. For format information, see SwiftRef in "SWIFTNetRequestAttribute". Real-time messages only. String -- O SwiftResponseRef The reference generated by the emitting SWIFTNet Link. For format information, see SwiftRequestRef in "SWIFTNetRequestAttribute". String -- O CBTReference The reference generated by the responding String application. Real-time messages only. -- O DuplCreation Indicates whether the response is a possible duplicate. -- O String Possible values are: • None • PDE Real-time messages only. 432 System Management Guide Appendix D - Message Formats Used in AI Element Description Type (1) From To -- O ValidationDescriptor MVal processing result of the response. Real-time messages only. Any AuthResult The authentication result of the response. String -- O Any (1) -- O Possible values are: • Success • Bypassed • Failed Real-time messages only. AuthValue The response authentication value. Real-time messages only. (1) These fields contain SWIFTNet data elements that are provided for purposes of completeness. Further processing of these elements is not required. SecurityAttribute Element Description Type SWIFTNetSecurityAttribute SWIFTNet security attributes. SWIFTNetSecurity Attribute From To M M From To SWIFTNetSecurityAttribute Element Description Type SigningRequired Indicates whether signing of the message is required upon emission. If specified, it overrides the Alliance Access emission profile configuration. Boolean O -- SignerDN The Signer DN String -- O Element Description Type From To NetworkDelivNotify Indicates whether a positive delivery notification is requested. Default value: false Boolean O -- Network The network over which the message was transmitted. String -- M String O O MessageTPI Possible values are: • ApplicationNetwork • SwiftNetNetwork • OtherNetwork NetworkPriority 15 July 2011 The Network priority. 433 Alliance Access 7.0.20 Element Description Type From To Possible values are: • Normal • Urgent If the field CBTPriority is not present (see "MessageLPI"), then its value is derived as follows: • Normal maps to 7 • Urgent maps to 5 Default value: Normal NetworkSessionNr The Network Session number. Integer -- M NetworkSeqNr The Network Sequence number. Integer -- M DuplCreation Indicates whether the message was marked as duplicate by the sender (PDE), or if the store-and-forward central system attempted to deliver the message multiple times (PDM). String -- O From To Possible values are: • None • PDM • PDE • PDE_PDM MessageSRI Element Description Type UserReference The Message User Reference. This corresponds to the SWIFTNet RequestRef (part of the InterAct RequestHeader) String(1..30) O O UserPDE The application indicates whether the message is a possible duplicate. Boolean O -- Element Description Type From To Addressee The address of the receiver of the original instance (see "AddressFullName"). AddressFullName -- M OrigMessageFields The level of detail that Alliance Access provides about the original message, as defined in the Alliance Access configuration. String -- M Report Possible values are: • NoOriginal 434 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To The next element ("OrigMessage") is not present. Used when the Message Partner is configured to never send the original messages for notifications. When the message partner is configured to include the original message in the report, the following values define the elements of the original message that are present in "OrigMessage": • Minimum • Condensed • Full • Expanded In this release, there is no distinction between the last 4 possibilities. OrigMessage always contains the full message details, including the MessageText. OrigMessage The original message. Message Not present if OrigMessageFields contains NoOriginal. -- O ReportLPI The report Local Processing Information. ReportLPI -- M ( TransmissionReport | Transmission report. TransmissionReport -- M DeliveryReport ) Delivery report. Indicates whether the message has been received by the correspondent or not. DeliveryReport -- M Element Description Type OrigSenderReference The Original Sender reference. MessageOrigin ReportLPI From To String(1..40) -- O The Alliance Access component that created the message. See "MessageOrigin" MessageOrigin -- M Modified Indicates whether the message has been modified within Alliance Access. Boolean -- O OriginalRelatedMessage Indicates whether this report is about an Original (true) or a Copy instance (false) of the message. Not applicable to MQSA. Boolean -- O ReportingApplication The Alliance Access application that generated the report. String -- M BackToNonOriginator Indicates whether the report is sent back to the entity that created the message in Alliance Access. Boolean -- O 15 July 2011 435 Alliance Access 7.0.20 Element Description Type From To -- O Not applicable to MQSA. DuplEmission Indicates whether Alliance Access already Boolean attempted to send this message instance to the application. TransmissionReport Element Description Type From To Network The network over which the message was transmitted. String -- M Possible values are: • ApplicationNetwork • SwiftNetNetwork • OtherNetwork NetworkAttribute The network attributes. NetworkAttribute -- M NetworkSessionNr The Network Session number. Integer -- M NetworkSeqNr The Network Sequence number. Integer -- M NetworkDeliveryStatus The network delivery status. String -- M Intervention [1..N] -- M Possible values are: • NetworkAcked • NetworkNacked • NetworkRejectedLocally The message was rejected by Alliance Access before emission. • NetworkAborted The message emission was aborted due to a communication error before the acknowledgement was received. • NetworkTimedOut The acknowledgement for the message was not received within the allowed time. • NetworkWaitingAck Transient state. Unless the Alliance Access routing is configured to do so, the last 3 values are not reported to the application. Interventions 436 The list of interventions. System Management Guide Appendix D - Message Formats Used in AI DeliveryReport Element Description Type From To Network The network over which the message was transmitted. String -- M Possible values are: • ApplicationNetwork • SwiftNetNetwork NetworkAttribute The network attributes. NetworkAttribute -- M NetworkSessionNr The Network Session number. Integer -- M NetworkSeqNr The Network Sequence number. Integer -- M ReceiverDeliveryStatus The delivery notification status. String -- M The list of interventions Intervention [1..N] -- M Element Description Type From To IntvCategory Intervention category. String -- M String -- M Possible values are: • RcvUnknown • RcvOverdue • RcvDelivered • RcvAborted • RcvDelayedNak • RcvAcked • RcvNacked • RcvTruncated Interventions Intervention Possible values are: • TransmissionReport • DeliveryReport • TransmissionResponse: can be present in TransmissionReport CreationTime The intervention creation time. Format: YYMMDDHHMMSS ApplicationOrigin The application that created the intervention. String -- M OperatorOrigin The name of operator that triggered the intervention creation. String -- M 15 July 2011 437 Alliance Access 7.0.20 Element Description Text The intervention text. Type Any (1) From To -- M (1) This field contains SWIFTNet data elements for Alliance intervention categories DeliveryReport and TransmissionResponse. For more information, see "Additional Information", "Creation of an Emission Appendix", "User Delivery Notifications from SWIFTNet Store-and-forward", and "Business Response for SWIFTNet RealTime". LogicalReply This element is used exclusively by MQSA. Element Description Type From To SenderReference Contains the UUMID of the message if it has been added to the Alliance Access database. Not present if the message has not been added. String(1..50) -- O SuccessIndication Indicates the result of the processing of the original message by MQSA: Boolean -- M Text associated with the error. Only present if SuccessIndication is false. String -- O Element Description Type From To ( Nickname | The correspondent nickname. Currently not applicable to MQSA. String(1..32) M -- FullName ) The correspondent full name. AddressFullName M M Element Description Type From To X1 The correspondent X1 part. The institution BIC11. String(11..11) M M X2 The correspondent X2 part. String(1..20) O O String(1..20) O O • true: if the message was added successfully by MQSA • false: if an error occurred during the processing of the message by MQSA ErrorText Address AddressFullName Present if correspondent type is: • Department • Application • Individual X3 438 The correspondent X3 part. System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To Present if correspondent type is: • Application contains routing information • Individual contains the last name X4 The correspondent X4 part. Present if correspondent type is Individual String(1..20) O O FinancialInstitution Name of the institution. String(1..105) O O BranchInformation Branch information. String(1..70) O O CityName City name. String(1..35) O O Location Location. String(1..105) O O CountryCode Country code. String(2..2) O O From To M -- O -- TargetApplication This element is not used by MQSA. Element Description Type TargetApplicationRule The routing function to be performed on the String message by Alliance Access. Possible values are: • InternalRouting The target routing point is determined by the Alliance Access routing rules. • CBTApplication The target routing point is determined by the value of DispositionState (see "MessageLPI"). • RoutingPointThe target routing point is specified in TargetRoutingPoint. TargetRoutingPoint The target routing point. Mandatory if TargetRoutingRule is "RoutingPoint". String(1..20) Element Description Type From To CBTApplication The Alliance Access application that created the message. String -- M MessageOrigin Possible values are: • ApplicationInterface • SwiftnetInterface 15 July 2011 439 Alliance Access 7.0.20 Element Description Type From To String -- O Integer -- O The sequence number. Mandatory when MessagePartner is present. Not applicable to MQSA. Integer -- O Element Description Type From To FormatAttributeMX MX format attributes FormatAttributeMX M M Element Description Type From To None Reserved for future use. • MessageEntry • MessengerAdapter • Other MessagePartner The Message Partner that created the message. Present if CBTApplication is ApplicationInterface. Not applicable to MQSA. SessionNr The session number. Present if CBTApplication is ApplicationInterface. Not applicable to MQSA. SeqNr FormatAttribute FormatAttributeMX D.5.1.1.4 Additional Information Introduction The elements described in this section are not included in the DataPDU schema described in "Structure of the DataPDU". • AckNack • SwGbl:Status • Sw:SnFPDMHistory • Sw:NotifSnFRequestHandle • SwInt:ValidationDescriptor These are Alliance Access or SWIFTNet specific data elements that Alliance Access provides to the application for completeness. Further processing of these elements is not required, but their structure is listed below. Note that the structure of these elements can evolve with future releases of SWIFTNet. 440 System Management Guide Appendix D - Message Formats Used in AI AckNack Element Description Type From To PseudoAckNack Alliance Access-generated Pseudo SWIFT Acknowledgement (for more information see "Creation of an Emission Appendix"). String -- M SwGbl:Status Optional SWIFTNet report status. SwGbl:Status -- O Element Description Type From To SwGbl:StatusAttributes Report status of top-level processing of SwGbl:StatusAttributes called function. Can occur multiple times [1..N] when the function does iterative processing (for example, a message validation function may return all syntax errors). -- M SwGbl:Status SwGbl:StatusAttributes Element Description Type From To SwGbl:Severity Possible values are: String -- M • Fatal • Transient • Logic • Success • Warning SwGbl:Code Status code. The list of error codes is available in SWIFTNet Link Error Codes (part of the SWIFTNet Link documentation set). String -- M SwGbl:Parameter Content depends on the error. Any [0..N] -- O SwGbl:Text Textual description. No processing, except display/print for information, must be performed on this element. String -- O SwGbl:Action Proposed corrective action. String -- O SwGbl:Details Lower level detailed report. SwGbl:Details [0..N] -- O Element Description Type From To SwGbl:Code Status code. String -- M SwGbl:Text Textual description. String -- O SwGbl:Action Proposed corrective action. String -- O SwGbl:Details An example of the SwGbl:Status can be found in the TranmissionReport samples listed in "File Transfer Examples". 15 July 2011 441 Alliance Access 7.0.20 Sw:SnFPDMHistory Element Description Type From To Sw:SnFPDMHistory In case of previous delivery attempts, gives the delivery attempt history. Sw:SnFDeliveryHistory -- M Sw:SnFDeliveryHistory Element Description Type From To Sw:SnFDeliveryInfo Message delivery information. In case of disaster take-over (SWIFT side), all messages present in the queue at the moment of the disaster are flagged for possible duplicate delivery, but without delivery information. Sw:SnFDeliveryInfo [0..N] -- O Sw:SnFDeliveryInfo Element Description Type From To Sw:SwiftTime SWIFT time of the delivery attempt (UTC). String -- O Format: YYYY-MM-DDTHH:MM:SSZ SwSec:UserDN Authoriser DN of the session owner. String -- O Sw:SnFSessionId Store-and-forward session identifier when the message was delivered. String -- O Format: <queue>:(d|p):<6 digit session number> SwInt:SNLId SNL ID of the physical SWIFTNet Link where message was delivered. String -- O Sw:RetryReason Reason why the message failed delivery. SwGbl:Status [0..1] -- O Sample SnFPDMHistory structure as described in the previous tables: <Sw:SnFPDMHistory> <Sw:SnFDeliveryInfo> <Sw:SwiftTime>2003-07-19T08:58:37Z</Sw:SwiftTime> <SwSec:UserDN>ou=zurich,o=bankwxyz,o=swift</SwSec:UserDN> <Sw:SnFSessionId>bankwxyz_applicq1:p:000458</Sw:SnFSessionId> <SwInt:SNLId>SNL00835D1</SwInt:SNLId> <Sw:RetryReason> <SwGbl:Status> <SwGbl:StatusAttributes> <SwGbl:Severity>Transient</SwGbl:Severity> <SwGbl:Code>See Error Guide</SwGbl:Code> <SwGbl:Text>One liner error description</SwGbl:Text> <SwGbl:Action>Retry Message</SwGbl:Action> </SwGbl:StatusAttributes> </SwGbl:Status> </Sw:RetryReason> </Sw:SnFDeliveryInfo> </Sw:SnFPDMHistory> 442 System Management Guide Appendix D - Message Formats Used in AI Sw:NotifySnFRequestHandle Element Description Type From To Sw:SnFRef Store-and-forward message reference of the notification. Contains the SwiftRef of the original message (see "SWIFTNetRequestAttribute"). String -- M Sw:SnFRefType Type of message for which this notification is provided. String -- M String -- M The SWIFT acceptance time of the request String ("Accepted", "Rejected") or generation time of the delivery notification request ("Failed") in UTC. -- M -- O Possible values: • InterAct Sw:AcceptStatus Type of store-and-forward notification Possible values: • Accepted: message accepted by the receiver • Rejected: message rejected by the receiver • Failed: SWIFT failed to deliver the message Sw:AckSwiftTime Format: YYYY-MM-DDTHH:MM:SSZ Sw:AckDescription Provides information about the acknowledgement. Free text. String In case the Sw:AcceptStatus is "Failed" (delivery notification generated by SWIFT), the Sw:AckDescription contains the following: • Message has expired (code SwGbl.MessageExpired) • Message delivery attempts exceeded system threshold (code SwGbl.MaxRetryExceeded) 15 July 2011 443 Alliance Access 7.0.20 Element Description Type From To Sw:AckInfo Provides information about the acknowledgement. Structured data that the client can analyse. String -- O In case the Sw:AcceptStatus is "Failed" (delivery notification generated by SWIFT), the Sw:AckInfo contains the following: SwRejectCode=<reject code> Where the reject code is: • SwGbl.MessageExpired • SwGbl.MaxRetryExceeded An example of this can be found in the DeliveryReport listed in "File Transfer Examples". SwInt:ValidationDescriptor Element Description Type From To SwInt:ValResult Indicates the result of validation. String -- M SwGbl:Status -- O Possible values: • Success • Warning • Fatal (not currently used) SwInt:ValStatus This contains the details of error(s) found. More than one SwGbl:StatusAttributes can be present. Present if SwInt:ValResult is different from Success. Example: <SwInt:ValResult>Warning</SwInt:ValResult> <SwInt:ValStatus> <SwGbl:StatusAttributes> <SwGbl:Severity>Warning</SwGbl:Severity> <SwGbl:Code></SwGbl:Code> <SwGbl:Text></SwGbl:Text> </SwGbl:StatusAttributes> </SwInt:ValStatus> D.5.1.2 Message Emission Flow D.5.1.2.1 Creation of an Emission Appendix Description An appendix holds the details of the emission or the reception of a message. This appendix is used to generate the Transmission Notification as described earlier in the Intervention Text of the TransmissionReport. 444 System Management Guide Appendix D - Message Formats Used in AI Creation of an Emission Appendix with this Information For each attempt to send a message, an emission appendix is created containing the following information: • IAPP name: SWIFTNet Network • Appendix type: Emission • Session Holder: The Emission Profile name • Session Number: The Session Number • Sequence Number: The Sequence Number • Receiver delivery status: – if no reconciliation: '-' – if reconciliation: "Delivered to receiver" • Network Delivery Status: Network ACK Generation of a Pseudo SWIFT Acknowledgement (ACKNAK) Upon unsuccessful emission the reason code is filled in the emission appendix in a Pseudo SWIFT acknowledgement described as follows. The ACKNAK element is not defined in the XSD specified in "Structure of the DataPDU". The Intervention Text being of type Any can contain any kind of information or free text message. Reason Code Text Transmission error T02 This contains all items where in <SwGbl:Status>, <SwGbl:Severity> Fatal or Transient and <SwGbl:Code> equals Sw.Gbl.NetworkTransmissionError. The text of the <SwGbl.Details><SwGbl:Code> (first occurrence) is put in the text of the appendix. If the <SwGbl.Details> is not present, then the text is empty. Unknown T03 All other cases: The text of the <SwGbl.Details><SwGbl:Code> (first occurrence) is put in the text of the appendix. If the <SwGbl.Details> is not present, then the text is empty. Upon (successful or unsuccessful) transmission response, the ack/nak text field of the emission appendix is updated and the <SwGbl:Status> is appended to the PseudoAckNack as follows: <AckNack><PseudoAckNack>{1:F21<BIC8(Sender_X1)>A<Branch(Sender_X1) <SessionNbr><SequenceNbr>}{4:{177:<LocalTime(YYMMDDHHMM)>} {451:0(Ack)/1(Nack)}[{405:<Code>}]{311:ACK/NAK\r\n<Text>} {108:<Message_User_Reference(1..16)>}}</PseudoAckNack> <SwGbl:Status>...</SwGbl:Status></AckNack> Transmission to Back Office Transmission notification is transmitted to the Back-Office through a TransmissionReport. 15 July 2011 445 Alliance Access 7.0.20 D.5.1.2.2 User Delivery Notifications from SWIFTNet Store-and-forward Description After successful emission to the store-and-forward central system, the following delivery notification can be received: • Successful delivery notification (optional): A User Delivery Report message (DELIVERED) is created and routed to the Traffic Reconciliation component. • Failed delivery notification: A User Delivery Report message (REJECTED) is created and routed to the Traffic Reconciliation component. Deliver notifications are reconciled with the original request. If the original message is found, then the emission appendix is updated with the delivery status. If TRS is configured to generate a delivery notification (Traffic recon - Delivery Notif), a pseudo User Delivery notification message (internal to Alliance Access) is created in the _TR_NOTIF routing point (with message nature NETWORK_MSG, Sender = DYLRXXXXXXX (in case of delivery notification) or ABLRXXXXXXX (in case of delayed NAK or abort notification), unit = None), and routed to the _TR_REC routing point with "Delivered" (positive delivery notification) or "Undelivered" (failed delivery notification) as processing result through an updated internal routing rule. Details of the delivery notification, as contained in the SWIFTNet data element NotifySnFRequestHandle of the received delivery notification, are also added as an intervention of category Deliveryreport to the original message instance by the standard TRREC functionality. The NotifySnFRequestHandle structure for SWIFTNet release 6.0.0 is shown in the following example (note the structure of this element can evolve with future releases of SWIFTNet): <Sw:NotifySnFRequestHandle> <Sw:SnFRef>SWITCH90-2005-05-25T15:51:14.9525.238697Z</Sw:SnFRef> <Sw:SnFRefType>InterAct</Sw:SnFRefType> <Sw:AcceptStatus>Accepted</Sw:AcceptStatus> <Sw:AckSwiftTime>2005-05-25T15:48:33Z</Sw:AckSwiftTime> <Sw:AckInfo>Acked</Sw:AckInfo> </Sw:NotifySnFRequestHandle> If the original message is not found, the notification is only journalised. Transmission to Back-Office The Alliance Delivery Notification instance created by TRREC is transmitted to the Back Office through a Delivery Report. Reconciliation at the back office can be done based on the UserReference. D.5.1.2.3 Business Response for SWIFTNet Real-Time Generation of a Transmission Response Intervention In real-time delivery mode, the response can be a business response. In such a case, the response payload (if any) is stored as an Intervention of a new category "Transmission response" and is appended to the original instance. If a Transmission Notification is created then it contains the date-time and sequence number of this intervention. 446 System Management Guide Appendix D - Message Formats Used in AI Transmission to Back-Office The business response can be transmitted to the back-office application through Transmission Report. It is the back-office responsibility to process the intervention accordingly. D.5.1.3 Message Reception Flow D.5.1.3.1 Real-Time Reception Description Messages are created in the _SI_from_SWIFTNet routing point and are immediately made available for processing (routed) to the back office. An empty InterAct response is generated for each message. Reception Appendix A reception appendix is created with the following key information: • IAPP Name: SWIFTNet Network • Appendix Type: Reception • Session Holder: SWIFTNet Link Endpoint on which the message was received (present in the SWIFTNet Link header) • Session Number: Current Session Number • Sequence Number: Current Sequence Number • Network Delivery Status: <empty> • Receiver Delivery Status: Receiver ACKed D.5.1.3.2 Store-and-forward Reception Description Store-and-forward messages can be received as soon as the queue is Active (acquired). Upon reception: • Messages are created in the _SI_from_SWIFTNet routing point and are immediately made available for processing (routed) to the back office. • Each message is acknowledged positively in the response sent to the central store-andforward engine. Reception Appendix A reception appendix is created for a requests delivery notification with the following key information: • IAPP Name: SWIFTNet Network • Appendix Type: Reception • Session Holder: Store-and-forward queue name 15 July 2011 447 Alliance Access 7.0.20 • Session Number: Session Number taken from the store-and-forward Session Identifier • Sequence Number: Sequence Number taken from the store-and-forward output sequence number • Network Delivery Status: ACKed D.5.1.4 File Transfer Examples Introduction The following sections show DataPDU examples for: • Store-and-forward: – Message sent by an application to Alliance Access – Transmission Report sent by Alliance Access to the application (ACK) – Transmission Report sent by Alliance Access to the application (Nack) This was triggered by putting an unknown tag in the message payload, causing a Message Validation error (MVal error) – Transmission Report (ACK) including the original message sent by Alliance Access to the application – Delivery Report sent by Alliance Access to the application – Message sent by Alliance Access to the application • Real time: – Message sent by an application to Alliance Access – Transmission Report Sent by Alliance Access to the application (including a real-time business response) D.5.1.4.1 Store-and-forward Message sent by an application to Alliance Access <?xml version="1.0" encoding="utf-8"?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01"> <Saa:Message> <Saa:MessageFormat>MX</Saa:MessageFormat> <Saa:MessageSubFormat>Input</Saa:MessageSubFormat> <Saa:Sender> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Sender> <Saa:Receiver> <Saa:FullName> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:MessageNature>FinancialNature</Saa:MessageNature> <Saa:MessageLPI> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> 448 System Management Guide Appendix D - Message Formats Used in AI <Saa:NRIndicator>true</Saa:NRIndicator> </Saa:SWIFTNetRequestAttribute> </Saa:NetworkAttribute> <Saa:SecurityAttribute> <Saa:SWIFTNetSecurityAttribute> <Saa:SigningRequired>true</Saa:SigningRequired> </Saa:SWIFTNetSecurityAttribute> </Saa:SecurityAttribute> </Saa:MessageLPI> <Saa:MessageTPI> <Saa:NetworkDelivNotify>true</Saa:NetworkDelivNotify> <Saa:NetworkPriority>Normal</Saa:NetworkPriority> </Saa:MessageTPI> <Saa:MessageSRI> <Saa:UserReference>Sample-XMLv1-0609141402</Saa:UserReference> </Saa:MessageSRI> <Saa:MessageText> <AppHdr xmlns="urn:swift:xsd:$ahV10"> <MsgRef>Sample-XMLv1-0609141402</MsgRef> <CrDate>2006-09-14T02:02:11.414</CrDate> </AppHdr> <Document xmlns="urn:swift:xsd:swift.if.ia$setr.016.001.02"> <setr.016.001.02> <RltdRef> <Ref>Ref123-1</Ref> </RltdRef> <IndvOrdrDtlsRpt> <Sts>PACK</Sts> <OrdrRef>Ref123-1</OrdrRef> </IndvOrdrDtlsRpt> </setr.016.001.02> </Document> </Saa:MessageText> </Saa:Message> </Saa:DataPDU> Transmission Report sent by Alliance Access to the application (Ack) <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv1-0609141402</ Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>NoOriginal</Saa:OrigMessageFields> <Saa:ReportLPI> <Saa:MessageOrigin> <Saa:CBTApplication>ApplicationInterface</Saa:CBTApplication> <Saa:MessagePartner>MXInput</Saa:MessagePartner> <Saa:SessionNr>0005</Saa:SessionNr> <Saa:SeqNr>000001</Saa:SeqNr> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:OriginalRelatedMessage>true</Saa:OriginalRelatedMessage> <Saa:ReportingApplication>SWIFTNet Interface</Saa:ReportingApplication> <Saa:BackToNonOriginator>true</Saa:BackToNonOriginator> </Saa:ReportLPI> <Saa:TransmissionReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> 15 July 2011 449 Alliance Access 7.0.20 <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-09-14T13:21:26.25214.2015075Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-09-14T13:21:24.55820.000505Z </Saa:SwiftRequestRef> <Saa:CBTReference>a7e67cde-e52a-4b0c-a3ad-af3f97dbaa6e</Saa:CBTReference> <Saa:SnFInputTime>0102:2006-09-14T13:13:12</Saa:SnFInputTime> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute> <Saa:ResponderDN>cn=messaging,o=swift,o=swift</Saa:ResponderDN> <Saa:SwiftResponseRef>snp00006-2006-09-14T13:21:48.25306.002002Z </Saa:SwiftResponseRef> </Saa:SWIFTNetResponseAttribute> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000005</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>060914152112</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <AckNack> <PseudoAckNack>{1:F21SAADBEBBAXXX000005000000001}{4:{177:0609141521} {451:0}{311:ACK}{108:Sample-XMLv1-0609141402}}</PseudoAckNack> </AckNack> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:TransmissionReport> </Saa:Report> </Saa:DataPDU> Transmission Report sent by Alliance Access to the application (Nack) <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv10609141402 </Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>NoOriginal</Saa:OrigMessageFields> <Saa:ReportLPI> <Saa:MessageOrigin> <Saa:CBTApplication>ApplicationInterface</Saa:CBTApplication> <Saa:MessagePartner>MXInput</Saa:MessagePartner> <Saa:SessionNr>0005</Saa:SessionNr> <Saa:SeqNr>000001</Saa:SeqNr> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:OriginalRelatedMessage>true</Saa:OriginalRelatedMessage> <Saa:ReportingApplication>SWIFTNet Interface</Saa:ReportingApplication> <Saa:BackToNonOriginator>true</Saa:BackToNonOriginator> </Saa:ReportLPI> <Saa:TransmissionReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> 450 System Management Guide Appendix D - Message Formats Used in AI <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:CBTReference>a7e67cde-e52a-4b0c-a3ad-af3f97dbaa6e</Saa:CBTReference> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute/> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000002</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000008</Saa:NetworkSeqNr> <Saa:NetworkDeliveryStatus>NetworkNacked</Saa:NetworkDeliveryStatus> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>061011143408</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <AckNack> <PseudoAckNack>{1:F21SAADBEBBAXXX000002000000008}{4:{177:0610111435} {451:1}{405:T02}{311:NAK Sw.WFE.eMVALError}{108:Sample-XMLv1-0609141402}}</ PseudoAckNack> <SwGbl:Status> <SwGbl:StatusAttributes> <SwGbl:Severity>Transient</SwGbl:Severity> <SwGbl:Code>Sw.Gbl.NetworkTransmissionError</SwGbl:Code> <SwGbl:Parameter>16899</SwGbl:Parameter> <SwGbl:Parameter>message validation failed with error</ SwGbl:Parameter> <SwGbl:Text>Network Transmission Error</SwGbl:Text> <SwGbl:Details> <SwGbl:Code>Sw.WFE.eMVALError</SwGbl:Code> <SwGbl:Text>MVAL component error., message validation failed with error</SwGbl:Text> </SwGbl:Details> <SwGbl:Details> <SwGbl:Code>Sw.WFE.ExecuteRequestFail</SwGbl:Code> <SwGbl:Text>Execute Request failed in WFE , MVAL</SwGbl:Text> </SwGbl:Details> <SwGbl:Details> <SwGbl:Code>Sw.WFE.ExecuteRequestFail</SwGbl:Code> <SwGbl:Text>Execute Request failed in WFE </SwGbl:Text> </SwGbl:Details> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr. 016.001.02[1]/IndvOrdrDtlsRpt1[1]</SwGbl:Parameter> <SwGbl:Text>unexpected content "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}IndvOrdrDtlsRpt1"; expected "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}MstrRef" or "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}IndvOrdrDtlsRpt" or "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}OrdrDtlsRpt" or "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}RltdRef"</SwGbl:Text> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr. 016.001.02[1]/IndvOrdrDtlsRpt1[1] </SwGbl:Parameter> <SwGbl:Text>no declaration for element "{urn:swift:xsd:swift.if.ia $setr.016.001.02}IndvOrdrDtlsRpt1"</SwGbl:Text> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> 15 July 2011 451 Alliance Access 7.0.20 <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr. 016.001.02[1]/IndvOrdrDtlsRpt1[1]/Sts[1]</SwGbl:Parameter> <SwGbl:Text>no declaration for element "{urn:swift:xsd:swift.if.ia $setr.016.001.02}Sts"</SwGbl:Text> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr. 016.001.02[1]/IndvOrdrDtlsRpt1[1]/OrdrRef[1]</SwGbl:Parameter> <SwGbl:Text>no declaration for element "{urn:swift:xsd:swift.if.ia $setr.016.001.02}OrdrRef"</SwGbl:Text> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr. 016.001.02[1]</SwGbl:Parameter> <SwGbl:Text>unexpected end of content</SwGbl:Text> </SwGbl:StatusAttributes> </SwGbl:Status> </AckNack> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:TransmissionReport> </Saa:Report> </Saa:DataPDU> Transmission Report (Ack) including the original message <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>Full</Saa:OrigMessageFields> <Saa:OrigMessage> <Saa:MessageFormat>MX</Saa:MessageFormat> <Saa:MessageSubFormat>Input</Saa:MessageSubFormat> <Saa:Sender> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Sender> <Saa:Receiver> <Saa:FullName> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:LiveMessage>true</Saa:LiveMessage> <Saa:MessageNature>FinancialNature</Saa:MessageNature> <Saa:MessageLPI> <Saa:OriginalMessage>false</Saa:OriginalMessage> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-09-14T13:21:26.25214.2015075Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-09-14T13:21:24.55820.000505Z </Saa:SwiftRequestRef> 452 System Management Guide Appendix D - Message Formats Used in AI <Saa:CBTReference>a7e67cde-e52a-4b0c-a3ad-af3f97dbaa6e</ Saa:CBTReference> <Saa:SnFInputTime>0102:2006-09-14T13:13:12</Saa:SnFInputTime> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute> <Saa:ResponderDN>cn=messaging,o=swift,o=swift</Saa:ResponderDN> <Saa:SwiftResponseRef>snp00006-2006-09-14T13:21:48.25306.002002Z </Saa:SwiftResponseRef> </Saa:SWIFTNetResponseAttribute> </Saa:NetworkAttribute> <Saa:SecurityAttribute> <Saa:SWIFTNetSecurityAttribute> <Saa:SignerDN>cn=rma2,o=saadbebb,o=swift</Saa:SignerDN> </Saa:SWIFTNetSecurityAttribute> </Saa:SecurityAttribute> <Saa:MessageOrigin> <Saa:CBTApplication>ApplicationInterface</Saa:CBTApplication> <Saa:MessagePartner>MXInput</Saa:MessagePartner> <Saa:SessionNr>0005</Saa:SessionNr> <Saa:SeqNr>000001</Saa:SeqNr> </Saa:MessageOrigin> <Saa:CBTRoutingInfo>MXAck</Saa:CBTRoutingInfo> </Saa:MessageLPI> <Saa:MessageTPI> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkPriority>Normal</Saa:NetworkPriority> <Saa:NetworkSessionNr>000005</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> </Saa:MessageTPI> <Saa:MessageSRI> <Saa:UserReference>Sample-XMLv1-0609141402</Saa:UserReference> </Saa:MessageSRI> <Saa:MessageText> <AppHdr xmlns="urn:swift:xsd:$ahV10"> <MsgRef>Sample-XMLv1-0609141402</MsgRef> <CrDate>2006-09-14T02:02:11.414</CrDate> </AppHdr> <Document xmlns="urn:swift:xsd:swift.if.ia$setr.016.001.02"> <setr.016.001.02> <RltdRef> <Ref>Ref123-1</Ref> </RltdRef> <IndvOrdrDtlsRpt> <Sts>PACK</Sts> <OrdrRef>Ref123-1</OrdrRef> </IndvOrdrDtlsRpt> </setr.016.001.02> </Document> </Saa:MessageText> </Saa:OrigMessage> <Saa:ReportLPI> <Saa:MessageOrigin> <Saa:CBTApplication>ApplicationInterface</Saa:CBTApplication> <Saa:MessagePartner>MXInput</Saa:MessagePartner> <Saa:SessionNr>0005</Saa:SessionNr> <Saa:SeqNr>000001</Saa:SeqNr> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:OriginalRelatedMessage>true</Saa:OriginalRelatedMessage> <Saa:ReportingApplication>SWIFTNet Interface</Saa:ReportingApplication> <Saa:BackToNonOriginator>true</Saa:BackToNonOriginator> </Saa:ReportLPI> <Saa:TransmissionReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> 15 July 2011 453 Alliance Access 7.0.20 <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-09-14T13:21:26.25214.2015075Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-09-14T13:21:24.55820.000505Z </Saa:SwiftRequestRef> <Saa:CBTReference>a7e67cde-e52a-4b0c-a3ad-af3f97dbaa6e</Saa:CBTReference> <Saa:SnFInputTime>0102:2006-09-14T13:13:12</Saa:SnFInputTime> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute> <Saa:ResponderDN>cn=messaging,o=swift,o=swift</Saa:ResponderDN> <Saa:SwiftResponseRef>snp00006-2006-09-14T13:21:48.25306.002002Z </Saa:SwiftResponseRef> </Saa:SWIFTNetResponseAttribute> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000005</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>060914152112</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <AckNack> <PseudoAckNack>{1:F21SAADBEBBAXXX000005000000001}{4:{177:0609141521} {451:0}{311:ACK}{108:Sample-XMLv1-0609141402}}</PseudoAckNack> </AckNack> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:TransmissionReport> </Saa:Report> </Saa:DataPDU> Delivery Report sent by Alliance Access to the application <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>NoOriginal</Saa:OrigMessageFields> <Saa:ReportLPI> <Saa:MessageOrigin> <Saa:CBTApplication>ApplicationInterface</Saa:CBTApplication> <Saa:MessagePartner>MXInput</Saa:MessagePartner> <Saa:SessionNr>0005</Saa:SessionNr> <Saa:SeqNr>000001</Saa:SeqNr> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:OriginalRelatedMessage>true</Saa:OriginalRelatedMessage> <Saa:ReportingApplication>Traffic Recon</Saa:ReportingApplication> <Saa:BackToNonOriginator>true</Saa:BackToNonOriginator> </Saa:ReportLPI> <Saa:DeliveryReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> 454 System Management Guide Appendix D - Message Formats Used in AI <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-09-14T13:21:26.25214.2015075Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-09-14T13:21:24.55820.000505Z </Saa:SwiftRequestRef> <Saa:CBTReference>a7e67cde-e52a-4b0c-a3ad-af3f97dbaa6e</Saa:CBTReference> <Saa:SnFInputTime>0102:2006-09-14T13:13:12</Saa:SnFInputTime> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute> <Saa:ResponderDN>cn=messaging,o=swift,o=swift</Saa:ResponderDN> <Saa:SwiftResponseRef>snp00006-2006-09-14T13:21:48.25306.002002Z </Saa:SwiftResponseRef> </Saa:SWIFTNetResponseAttribute> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000005</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> <Saa:ReceiverDeliveryStatus>RcvDelivered</Saa:ReceiverDeliveryStatus> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>DeliveryReport</Saa:IntvCategory> <Saa:CreationTime>060914152453</Saa:CreationTime> <Saa:ApplicationOrigin>TRS</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <Sw:NotifySnFRequestHandle> <Sw:SnFRef>SWITCH90-2006-09-14T13:21:26.25214.2015075Z</Sw:SnFRef> <Sw:SnFRefType>InterAct</Sw:SnFRefType> <Sw:AcceptStatus>Accepted</Sw:AcceptStatus> <Sw:AckSwiftTime>2006-09-14T13:21:50Z</Sw:AckSwiftTime> <Sw:AckInfo>Acked</Sw:AckInfo> </Sw:NotifySnFRequestHandle> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:DeliveryReport> </Saa:Report> </Saa:DataPDU> Message sent by Alliance Access to the application <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>OSAADBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:Message> <Saa:MessageFormat>MX</Saa:MessageFormat> <Saa:MessageSubFormat>Output</Saa:MessageSubFormat> <Saa:Sender> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Sender> <Saa:Receiver> <Saa:FullName> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:LiveMessage>true</Saa:LiveMessage> <Saa:MessageNature>FinancialNature</Saa:MessageNature> <Saa:MessageLPI> <Saa:OriginalMessage>true</Saa:OriginalMessage> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> 15 July 2011 455 Alliance Access 7.0.20 <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-09-14T13:21:26.25214.2015075Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-09-14T13:21:24.55820.000505Z </Saa:SwiftRequestRef> <Saa:CBTReference>e6af835e-1dd1-11b2-9214-092595955b82</Saa:CBTReference> <Saa:SNLEndPoint>sni_sms6560</Saa:SNLEndPoint> <Saa:SnFQueueName>saadbebb_ifia</Saa:SnFQueueName> <Saa:ValidationDescriptor> <SwInt:ValResult>Success</SwInt:ValResult> </Saa:ValidationDescriptor> <Saa:AuthResult>Success</Saa:AuthResult> <Saa:AuthValue> <SwSec:CryptoInternal> <SwSec:CipherKey>UEVNRkBQcm9jLVR5cGU6IDQsTUlDLU9OTFkNCkNvbnRlbnQtRG9tYWluOiBSR kM4MjINCkVudHJ1c3RGaWxlLVZlcnNpb246IDIuMA0KT3JpZ2luYXRvci1ETjogY249cm1hMixvPXN hYWRiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDc3ODU1NjYNCk1JQy1JbmZvOiBTSEExLCBSU0EsD QogcnhjSVAzWEdjRVdOWnBTYjJ0Y2tjenFOc25nMG5rRk15R0FrSDhkRHZhM203MlR1ellQUjl1VFl mRWNUb1VTZA0KIHlVR3ROVkV1eWFkM2ltblA5akJiQVhjN0c4ekpmVUlnaWgyWVgwcWc0QTF6UFV5T EJXcmVOOGdNWFBiVndKd1YNCiBEdXFKK0svdk9PM2VwY2VEeEYzWkhIS1BKY000Y0NSYkFMQXBlYWl 1ZGxyUWRLZVV5Q3lsOThpOHNuNFQ4UWhpDQogUjB3VFZJeWk0RTNnY3FFSC9ubFV5M082ZnBtNFlCN kl6TWYxNVEzVVZONHdMVnhCNEpkSjJveGVpelBIYlVqVg0KIENabUNmSEg5dTBsb0pWTjd4TlpKWXh sRmRybjFPd2Jlc3RETTlTSmNPUjY1OFg5WFhKV3NWWXphT08xQTg1cCsNCiAwNFFzU0k2NlVZR2ZXe m1TaStIVVRnPT0NCg==</SwSec:CipherKey> <SwSec:CryptoProtocol>4.0:3.0</SwSec:CryptoProtocol> </SwSec:CryptoInternal> <SwSec:CryptoDescriptor> <SwSec:MemberRef>RequestPayload</SwSec:MemberRef> <SwSec:MemberRef>RequestHeader</SwSec:MemberRef> <SwSec:MemberRef>RequestDescriptor.SwiftRequestRef</SwSec:MemberRef> <SwSec:SignDN>cn=rma2,o=saadbebb,o=swift</SwSec:SignDN> <SwSec:CertPolicyId>1.3.21.6.2</SwSec:CertPolicyId> </SwSec:CryptoDescriptor> </Saa:AuthValue> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute/> </Saa:NetworkAttribute> <Saa:SecurityAttribute> <Saa:SWIFTNetSecurityAttribute> <Saa:SignerDN>cn=rma2,o=saadbebb,o=swift</Saa:SignerDN> </Saa:SWIFTNetSecurityAttribute> </Saa:SecurityAttribute> <Saa:MessageOrigin> <Saa:CBTApplication>SwiftnetInterface</Saa:CBTApplication> </Saa:MessageOrigin> <Saa:CBTRoutingInfo>MXRecv</Saa:CBTRoutingInfo> </Saa:MessageLPI> <Saa:MessageTPI> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkPriority>Normal</Saa:NetworkPriority> <Saa:NetworkSessionNr>979896</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000001559</Saa:NetworkSeqNr> <Saa:DuplCreation>PDE</Saa:DuplCreation> </Saa:MessageTPI> <Saa:MessageSRI> <Saa:UserReference>Sample-XMLv1-0609141402</Saa:UserReference> </Saa:MessageSRI> <Saa:MessageText> <AppHdr xmlns="urn:swift:xsd:$ahV10"> <MsgRef>Sample-XMLv1-0609141402</MsgRef> <CrDate>2006-09-14T02:02:11.414</CrDate> </AppHdr> <Document xmlns="urn:swift:xsd:swift.if.ia$setr.016.001.02"> <setr.016.001.02> <RltdRef> 456 System Management Guide Appendix D - Message Formats Used in AI <Ref>Ref123-1</Ref> </RltdRef> <IndvOrdrDtlsRpt> <Sts>PACK</Sts> <OrdrRef>Ref123-1</OrdrRef> </IndvOrdrDtlsRpt> </setr.016.001.02> </Document> </Saa:MessageText> </Saa:Message> </Saa:DataPDU> D.5.1.4.2 Real time Message sent by an application to Alliance Access <?xml version="1.0" encoding="utf-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01"> <Saa:Message> <Saa:MessageFormat>MX</Saa:MessageFormat> <Saa:MessageSubFormat>Input</Saa:MessageSubFormat> <Saa:Sender> <Saa:X1>SAASBEBBXXX</Saa:X1> </Saa:Sender> <Saa:Receiver> <Saa:FullName> <Saa:X1>SAATBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:MessageNature>FinancialNature</Saa:MessageNature> <Saa:MessageLPI> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saasbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>cn=beso,cn=tg229,o=saatbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.cashrepv1</Saa:Service> <Saa:RequestType>getaccount</Saa:RequestType> </Saa:SWIFTNetRequestAttribute> </Saa:NetworkAttribute> </Saa:MessageLPI> <Saa:MessageTPI> <Saa:NetworkPriority>Normal</Saa:NetworkPriority> </Saa:MessageTPI> <Saa:MessageSRI> <Saa:UserReference>REF-1-0609181711</Saa:UserReference> </Saa:MessageSRI> <Saa:MessageText> <Ah:AppHdr xmlns:Ah="urn:swift:xsd:$ahV10"> <Ah:MsgRef>SCRRQ01</Ah:MsgRef> <Ah:CrDate>2006-09-18T17:11:28.359</Ah:CrDate> </Ah:AppHdr> <Doc:Document xmlns:Doc="urn:swift:xsd:swift.cashrepv1$getaccount" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Doc:getaccount> <Doc:NstrAcctSchCrit> <Doc:AcctId> <Doc:DmstAcct>789DA123</Doc:DmstAcct> </Doc:AcctId> <Doc:BalTp>AVLB</Doc:BalTp> </Doc:NstrAcctSchCrit> <Doc:QryPrcg> <Doc:QryRef> <Doc:Ref>SCRRQ01</Doc:Ref> </Doc:QryRef> </Doc:QryPrcg> </Doc:getaccount> </Doc:Document> 15 July 2011 457 Alliance Access 7.0.20 </Saa:MessageText> </Saa:Message> </Saa:DataPDU> Transmission Report sent by Alliance Access to the application <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAATBEBBXXXMX REF-1-0609181711</Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAATBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>NoOriginal</Saa:OrigMessageFields> <Saa:ReportLPI> <Saa:MessageOrigin> <Saa:CBTApplication>ApplicationInterface</Saa:CBTApplication> <Saa:MessagePartner>MXFileInput</Saa:MessagePartner> <Saa:SessionNr>0017</Saa:SessionNr> <Saa:SeqNr>000001</Saa:SeqNr> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:OriginalRelatedMessage>true</Saa:OriginalRelatedMessage> <Saa:ReportingApplication>SWIFTNet Interface</Saa:ReportingApplication> <Saa:BackToNonOriginator>true</Saa:BackToNonOriginator> </Saa:ReportLPI> <Saa:TransmissionReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saasbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>cn=beso,cn=tg229,o=saatbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.cashrepv1</Saa:Service> <Saa:RequestType>getaccount</Saa:RequestType> <Saa:SwiftRef>SWITCH90-2006-09-18T15:12:41.24521.1424140Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL00229-2006-09-18T15:12:39.5656.000017Z </Saa:SwiftRequestRef> <Saa:CBTReference>b12ba774-c3bf-47df-9e8a-924282c3235c</Saa:CBTReference> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute> <Saa:ResponderDN>cn=beso,cn=tg229,o=saatbebb,o=swift</Saa:ResponderDN> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftResponseRef>SNL00229-2006-09-18T15:12:41.5304.000011Z </Saa:SwiftResponseRef> <Saa:AuthResult>Success</Saa:AuthResult> <Saa:AuthValue> <SwSec:CryptoInternal> <SwSec:CipherKey>UEVNRkBQcm9jLVR5cGU6IDQsTUlDLU9OTFkNCkNvbnRlbnQtRG9tYWluOiBSR kM4MjINCkVudHJ1c3RGaWxlLVZlcnNpb246IDIuMA0KT3JpZ2luYXRvci1ETjogY249cm1hNCxvPXN hYXRiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDE5Mzg1MjINCk1JQy1JbmZvOiBTSEExLCBSU0EsD QogVmFTNlpqMC9rYnQrZVF0dHRhNmQvcnpPdVhmL3prc1NTeXBSc1RGWUxQOHAzazFLSDFOVnZacGF XWDhoVTY4bg0KIFo4a1h3a2g1Q3VYNFgvenNQZUdtS1pKWTBvWVZXM3c1cmdyYm5YMjVzQml5cURVc y9MYlRxci8wV0dIaUI4ZWQNCiBzR0xRenFRNFh3VmxGRmlUN0FxWjErUHovQURmQlFmemd2N1JibWp HWWxrTk54NVNpMUk4ajZ5VjU3bnBpSCtVDQogM21MWmhuUFNvcThZbEZIVEhzS3dCOExWNko0U25yb zd1NWRVc2ZjZUVqbUVZeERGK21qaXlwSytXaUdTVWZlWg0KIE01R21nUk9rb0k5N2k4STZ4d2J4QUd lL3UrZ0M4enJ5NUd1SHVtTElXcHpRUEsvejVGWmRSTEpqajNGaXJKZW0NCiAyU2pucXo5OXNEWUF1b WJBT0E5N25RPT0NCg==</SwSec:CipherKey> <SwSec:CryptoProtocol>4.0:3.0</SwSec:CryptoProtocol> </SwSec:CryptoInternal> <SwSec:CryptoDescriptor> <SwSec:MemberRef>ResponsePayload</SwSec:MemberRef> <SwSec:MemberRef>ResponseHeader</SwSec:MemberRef> <SwSec:MemberRef>ResponseDescriptor.SwiftResponseRef</SwSec:MemberRef> <SwSec:SignDN>cn=rma4,o=saatbebb,o=swift</SwSec:SignDN> 458 System Management Guide Appendix D - Message Formats Used in AI <SwSec:CertPolicyId>1.3.21.6.2</SwSec:CertPolicyId> </SwSec:CryptoDescriptor> </Saa:AuthValue> </Saa:SWIFTNetResponseAttribute> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000005</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000002</Saa:NetworkSeqNr> <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>060918171236</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <AckNack> <PseudoAckNack>{1:F21SAASBEBBAXXX000005000000002}{4:{177:0609181712} {451:0}{311:ACK}{108:REF-1-0609181711}}</PseudoAckNack> </AckNack> </Saa:Text> </Saa:Intervention> <Saa:Intervention> <Saa:IntvCategory>TransmissionResponse</Saa:IntvCategory> <Saa:CreationTime>060918171242</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <Ah:AppHdr xmlns:Ah="urn:swift:xsd:$ahV10"> <Ah:MsgRef>ra01</Ah:MsgRef> <Ah:CrDate>2006-09-18T17:12:30</Ah:CrDate> </Ah:AppHdr> <Doc:Document xmlns:Doc="urn:swift:xsd:swift.cashrepv1$returnaccount" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Doc:returnaccount> <Doc:QryRef> <Doc:Ref>SCRRQ01</Doc:Ref> </Doc:QryRef> <Doc:RtrRef> <Doc:Ref>RS01</Doc:Ref> </Doc:RtrRef> <Doc:Accts> <Doc:AcctRpt> <Doc:AcctId> <Doc:DmstAcct>789DA123</Doc:DmstAcct> </Doc:AcctId> <Doc:Acct> <Doc:Ccy>EUR</Doc:Ccy> <Doc:Bal> <Doc:Amt>99733.03</Doc:Amt> <Doc:CdtDbtInd>CRDT</Doc:CdtDbtInd> <Doc:ValDt> <Doc:Dt>2006-09-18</Doc:Dt> </Doc:ValDt> <Doc:Tp>AVLB</Doc:Tp> </Doc:Bal> </Doc:Acct> </Doc:AcctRpt> </Doc:Accts> </Doc:returnaccount> </Doc:Document> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:TransmissionReport> </Saa:Report> </Saa:DataPDU> 15 July 2011 459 Alliance Access 7.0.20 D.5.1.5 MQSA Examples Introduction The following sections show DataPDU examples for: • Store-and-forward – Message sent by an application to Alliance Access – Transmission Report sent by Alliance Access to the application (ACK) – Transmission Report sent by Alliance Access to the application (Nack) This was triggered by putting an unknown tag in the message payload, causing a Message Validation error (MVal error). – Transmission Report (ACK) including the original message – Delivery Report sent by Alliance Access to the application – Message sent by Alliance Access to the application • Real time – Message sent by an application to Alliance Access – Transmission Report sent by Alliance Access to the application (including a real-time business response) D.5.1.5.1 Store-and-forward Message sent by an application to MQSA <?xml version="1.0" encoding="utf-8"?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01"> <Saa:Message> <Saa:MessageFormat>MX</Saa:MessageFormat> <Saa:MessageSubFormat>Input</Saa:MessageSubFormat> <Saa:Sender> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Sender> <Saa:Receiver> <Saa:FullName> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:MessageNature>FinancialNature</Saa:MessageNature> <Saa:MessageLPI> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NRIndicator>true</Saa:NRIndicator> </Saa:SWIFTNetRequestAttribute> </Saa:NetworkAttribute> <Saa:SecurityAttribute> <Saa:SWIFTNetSecurityAttribute> <Saa:SigningRequired>true</Saa:SigningRequired> </Saa:SWIFTNetSecurityAttribute> </Saa:SecurityAttribute> </Saa:MessageLPI> <Saa:MessageTPI> 460 System Management Guide Appendix D - Message Formats Used in AI <Saa:NetworkDelivNotify>true</Saa:NetworkDelivNotify> <Saa:NetworkPriority>Normal</Saa:NetworkPriority> </Saa:MessageTPI> <Saa:MessageSRI> <Saa:UserReference>Sample-XMLv1-0609141402</Saa:UserReference> </Saa:MessageSRI> <Saa:MessageText> <AppHdr xmlns="urn:swift:xsd:$ahV10"> <MsgRef>Sample-XMLv1-0609141402</MsgRef> <CrDate>2006-09-14T02:02:11.414</CrDate> </AppHdr> <Document xmlns="urn:swift:xsd:swift.if.ia$setr.016.001.02"> <setr.016.001.02> <RltdRef> <Ref>Ref123-1</Ref> </RltdRef> <IndvOrdrDtlsRpt> <Sts>PACK</Sts> <OrdrRef>Ref123-1</OrdrRef> </IndvOrdrDtlsRpt> </setr.016.001.02> </Document> </Saa:MessageText> </Saa:Message> </Saa:DataPDU> Logical reply sent by MQSA to the application <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:LogicalReply> <Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:SuccessIndication>true</Saa:SuccessIndication> </Saa:LogicalReply> </Saa:DataPDU> Transmission Report sent by MQSA to the application (Ack) <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>NoOriginal</Saa:OrigMessageFields> <Saa:ReportLPI> <Saa:OrigSenderReference>QU1RIFFNLkJFV1gxMjQgIIO0D0UgAA0B </Saa:OrigSenderReference> <Saa:MessageOrigin> <Saa:CBTApplication>Other</Saa:CBTApplication> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:ReportingApplication>SWIFTNet Interface</Saa:ReportingApplication> <Saa:DuplEmission>false</Saa:DuplEmission> </Saa:ReportLPI> <Saa:TransmissionReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> 15 July 2011 461 Alliance Access 7.0.20 <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-09-19T12:38:41.25857.1220138Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-09-19T12:38:41.6596.000073Z </Saa:SwiftRequestRef> <Saa:CBTReference>39d39f5a-fc26-4e5d-92f8-3bb42f4352f6</Saa:CBTReference> <Saa:SnFInputTime>0102:2006-09-19T12:30:25</Saa:SnFInputTime> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute /> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000003</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>060919143839</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <AckNack> <PseudoAckNack>{1:F21SAADBEBBAXXX000003000000001}{4:{177:0609191438} {451:0}{311:ACK}{108:Sample-XMLv1-0609141402}}</PseudoAckNack> </AckNack> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:TransmissionReport> </Saa:Report> </Saa:DataPDU> Transmission Report sent by Alliance Access to the application (Nack) <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAAIBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>NoOriginal</Saa:OrigMessageFields> <Saa:ReportLPI> <Saa:OrigSenderReference>QU1RIFFNLk1YUyAgICAgIHTRLEUgACIC </Saa:OrigSenderReference> <Saa:MessageOrigin> <Saa:CBTApplication>Other</Saa:CBTApplication> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:ReportingApplication>SWIFTNet Interface</Saa:ReportingApplication> <Saa:DuplEmission>false</Saa:DuplEmission> </Saa:ReportLPI> <Saa:TransmissionReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:CBTReference>0201e4e5-c347-4ed3-a96a-2c0eab280749</Saa:CBTReference> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute /> 462 System Management Guide Appendix D - Message Formats Used in AI </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000001</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> <Saa:NetworkDeliveryStatus>NetworkNacked</Saa:NetworkDeliveryStatus> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>061011153702</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <AckNack> <PseudoAckNack>{1:F21SAAIBEBBAXXX000001000000001}{4:{177:0610111538} {451:1}{405:T02}{311:NAK Sw.WFE.eMVALError}{108:Sample-XMLv1-0609141402}} </PseudoAckNack> <SwGbl:Status> <SwGbl:StatusAttributes> <SwGbl:Severity>Transient</SwGbl:Severity> <SwGbl:Code>Sw.Gbl.NetworkTransmissionError</SwGbl:Code> <SwGbl:Parameter>3979</SwGbl:Parameter> <SwGbl:Parameter>message validation failed with error</ SwGbl:Parameter> <SwGbl:Text>Network Transmission Error</SwGbl:Text> <SwGbl:Details> <SwGbl:Code>Sw.WFE.eMVALError</SwGbl:Code> <SwGbl:Text>MVAL component error., message validation failed with error</SwGbl:Text> </SwGbl:Details> <SwGbl:Details> <SwGbl:Code>Sw.WFE.ExecuteRequestFail</SwGbl:Code> <SwGbl:Text>Execute Request failed in WFE , MVAL</SwGbl:Text> </SwGbl:Details> <SwGbl:Details> <SwGbl:Code>Sw.WFE.ExecuteRequestFail</SwGbl:Code> <SwGbl:Text>Execute Request failed in WFE</SwGbl:Text> </SwGbl:Details> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr.016.001.02[1]/ IndvOrdrDtlsRpt1[1]</SwGbl:Parameter> <SwGbl:Text>unexpected content "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}IndvOrdrDtlsRpt1"; expected "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}MstrRef" or "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}IndvOrdrDtlsRpt" or "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}OrdrDtlsRpt" or "{urn:swift:xsd:swift.if.ia$setr. 016.001.02}RltdRef"</SwGbl:Text> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr. 016.001.02[1]/IndvOrdrDtlsRpt1[1]</SwGbl:Parameter> <SwGbl:Text>no declaration for element "{urn:swift:xsd:swift.if.ia $setr.016.001.02}IndvOrdrDtlsRpt1"</SwGbl:Text> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr. 016.001.02[1]/IndvOrdrDtlsRpt1[1]/Sts[1]</SwGbl:Parameter> <SwGbl:Text>no declaration for element "{urn:swift:xsd:swift.if.ia $setr.016.001.02}Sts"</SwGbl:Text> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> 15 July 2011 463 Alliance Access 7.0.20 <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr. 016.001.02[1]/IndvOrdrDtlsRpt1[1]/OrdrRef[1]</SwGbl:Parameter> <SwGbl:Text>no declaration for element "{urn:swift:xsd:swift.if.ia $setr.016.001.02}OrdrRef"</SwGbl:Text> </SwGbl:StatusAttributes> <SwGbl:StatusAttributes> <SwGbl:Severity>Fatal</SwGbl:Severity> <SwGbl:Code>Sw.MVAL.SyntaxError</SwGbl:Code> <SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr.016.001.02[1] </SwGbl:Parameter> <SwGbl:Text>unexpected end of content</SwGbl:Text> </SwGbl:StatusAttributes> </SwGbl:Status> </AckNack> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:TransmissionReport> </Saa:Report> </Saa:DataPDU> Transmission Report (Ack) including the original message <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>Full</Saa:OrigMessageFields> <Saa:OrigMessage> <Saa:MessageFormat>MX</Saa:MessageFormat> <Saa:MessageSubFormat>Input</Saa:MessageSubFormat> <Saa:Sender> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Sender> <Saa:Receiver> <Saa:FullName> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:LiveMessage>true</Saa:LiveMessage> <Saa:MessageNature>FinancialNature</Saa:MessageNature> <Saa:MessageLPI> <Saa:OriginalMessage>false</Saa:OriginalMessage> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-10-18T09:13:49.15784.012942Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-10-18T09:13:48.3040.001280Z </Saa:SwiftRequestRef> <Saa:CBTReference>0aad3ea0-2d15-4d2d-8ce5-e6dfe47cdb4c </Saa:CBTReference> <Saa:SnFInputTime>0102:2006-10-18T09:05:21</Saa:SnFInputTime> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute /> </Saa:NetworkAttribute> <Saa:SecurityAttribute> 464 System Management Guide Appendix D - Message Formats Used in AI <Saa:SWIFTNetSecurityAttribute> <Saa:SignerDN>cn=rma2,o=saadbebb,o=swift</Saa:SignerDN> </Saa:SWIFTNetSecurityAttribute> </Saa:SecurityAttribute> <Saa:MessageOrigin> <Saa:CBTApplication>Other</Saa:CBTApplication> </Saa:MessageOrigin> <Saa:CBTRoutingInfo>SMQS_To_MQSeries</Saa:CBTRoutingInfo> <Saa:DuplEmission>false</Saa:DuplEmission> </Saa:MessageLPI> <Saa:MessageTPI> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkPriority>Normal</Saa:NetworkPriority> <Saa:NetworkSessionNr>000003</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> </Saa:MessageTPI> <Saa:MessageSRI> <Saa:UserReference>Sample-XMLv1-0609141402</Saa:UserReference> </Saa:MessageSRI> <Saa:MessageText> <AppHdr xmlns="urn:swift:xsd:$ahV10"> <MsgRef>Sample-XMLv1-0609141402</MsgRef> <CrDate>2006-09-14T02:02:11.414</CrDate> </AppHdr> <Document xmlns="urn:swift:xsd:swift.if.ia$setr.016.001.02"> <setr.016.001.02> <RltdRef> <Ref>Ref123-1</Ref> </RltdRef> <IndvOrdrDtlsRpt> <Sts>PACK</Sts> <OrdrRef>Ref123-1</OrdrRef> </IndvOrdrDtlsRpt> </setr.016.001.02> </Document> </Saa:MessageText> </Saa:OrigMessage> <Saa:ReportLPI> <Saa:OrigSenderReference>QU1RIFFNLk1YUyAgICAgII7oNUUgAF8E </Saa:OrigSenderReference> <Saa:MessageOrigin> <Saa:CBTApplication>Other</Saa:CBTApplication> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:ReportingApplication>SWIFTNet Interface</Saa:ReportingApplication> <Saa:DuplEmission>false</Saa:DuplEmission> </Saa:ReportLPI> <Saa:TransmissionReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-10-18T09:13:49.15784.012942Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-10-18T09:13:48.3040.001280Z </Saa:SwiftRequestRef> <Saa:CBTReference>0aad3ea0-2d15-4d2d-8ce5-e6dfe47cdb4c</Saa:CBTReference> <Saa:SnFInputTime>0102:2006-10-18T09:05:21</Saa:SnFInputTime> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute /> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000003</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus> 15 July 2011 465 Alliance Access 7.0.20 <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>061018111349</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <AckNack> <PseudoAckNack>{1:F21SAADBEBBAXXX000003000000001}{4:{177:0610181113} {451:0}{311:ACK}{108:Sample-XMLv1-0609141402}}</PseudoAckNack> </AckNack> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:TransmissionReport> </Saa:Report> </Saa:DataPDU> Delivery Report sent by MQSA to the application <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>NoOriginal</Saa:OrigMessageFields> <Saa:ReportLPI> <Saa:OrigSenderReference>QU1RIFFNLkJFV1gxMjQgIIO0D0UgAA0B </Saa:OrigSenderReference> <Saa:MessageOrigin> <Saa:CBTApplication>Other</Saa:CBTApplication> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:ReportingApplication>Traffic Recon</Saa:ReportingApplication> <Saa:DuplEmission>false</Saa:DuplEmission> </Saa:ReportLPI> <Saa:DeliveryReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-09-19T12:38:41.25857.1220138Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-09-19T12:38:41.6596.000073Z </Saa:SwiftRequestRef> <Saa:CBTReference>39d39f5a-fc26-4e5d-92f8-3bb42f4352f6</Saa:CBTReference> <Saa:SnFInputTime>0102:2006-09-19T12:30:25</Saa:SnFInputTime> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute /> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000003</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000001</Saa:NetworkSeqNr> <Saa:ReceiverDeliveryStatus>RcvDelivered</Saa:ReceiverDeliveryStatus> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>DeliveryReport</Saa:IntvCategory> <Saa:CreationTime>060919143932</Saa:CreationTime> <Saa:ApplicationOrigin>TRS</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> 466 System Management Guide Appendix D - Message Formats Used in AI <Saa:Text> <Sw:NotifySnFRequestHandle> <Sw:SnFRef>SWITCH90-2006-09-19T12:38:41.25857.1220138Z</Sw:SnFRef> <Sw:SnFRefType>InterAct</Sw:SnFRefType> <Sw:AcceptStatus>Accepted</Sw:AcceptStatus> <Sw:AckSwiftTime>2006-09-19T12:39:34Z</Sw:AckSwiftTime> <Sw:AckInfo>Acked</Sw:AckInfo> </Sw:NotifySnFRequestHandle> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:DeliveryReport> </Saa:Report> </Saa:DataPDU> Message sent by MQSA to the application <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>OSAADBEBBXXX016Sample-XMLv1-0609141402 </Saa:SenderReference> <Saa:Message> <Saa:MessageFormat>MX</Saa:MessageFormat> <Saa:MessageSubFormat>Output</Saa:MessageSubFormat> <Saa:Sender> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:Sender> <Saa:Receiver> <Saa:FullName> <Saa:X1>SAADBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:LiveMessage>true</Saa:LiveMessage> <Saa:MessageNature>FinancialNature</Saa:MessageNature> <Saa:MessageLPI> <Saa:OriginalMessage>true</Saa:OriginalMessage> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saadbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>o=saadbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.if.ia</Saa:Service> <Saa:RequestType>setr.016.001.02</Saa:RequestType> <Saa:NonRepType>SvcMand</Saa:NonRepType> <Saa:SwiftRef>SWITCH90-2006-09-19T12:38:41.25857.1220138Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL10391-2006-09-19T12:38:41.6596.000073Z </Saa:SwiftRequestRef> <Saa:CBTReference>79793722-19ac-4d6d-ad7e-a755349285ed</Saa:CBTReference> <Saa:SNLEndPoint>sni_bewx124</Saa:SNLEndPoint> <Saa:SnFQueueName>saadbebb_ifia</Saa:SnFQueueName> <Saa:ValidationDescriptor> <SwInt:ValResult>Success</SwInt:ValResult> </Saa:ValidationDescriptor> <Saa:AuthResult>Success</Saa:AuthResult> <Saa:AuthValue> <SwSec:CryptoInternal> <SwSec:CipherKey>UEVNRkBQcm9jLVR5cGU6IDQsTUlDLU9OTFkNCkNvbnRlbnQtRG9tYWluOiBSR kM4MjINCkVudHJ1c3RGaWxlLVZlcnNpb246IDIuMA0KT3JpZ2luYXRvci1ETjogY249cm1hMixvPXN hYWRiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDc3ODU1NjYNCk1JQy1JbmZvOiBTSEExLCBSU0EsD QogdUlTY2tYSkV1akFUQSt5bWFnaWJRU1I3b3B5Q3JheGV0L0ExZ2QzRy9mQkdyT0JZZmc1LzZIbzY 4S1hjdjFyRg0KIDQ5aHgxWWRWeDlyMElLMHZld2xHRnBVRUErdzhUcktzMG95QTFDbXd3am5iR1I5T U92aWtGK01hNTQ2N3dXSHMNCiAxZU5Odk5zY0tNVHYyb2grU0RrcW9xS1hUUy8zQXpNNFphL2NCR25 PYUN2MEFocXFaQUFTazFneTE3c3dZMURlDQogNzhYYi9tdnMvRVZBT1o0RnY4MUhzWWhnM2lwNHRUO EVlYnVNdFpvZDMycVkwemFLVVMrcUtGL2VwVjRQM2syMA0KIGMvaWJJc3ZKc1pCTTlQbzAyT1JyNXB 15 July 2011 467 Alliance Access 7.0.20 sS1p1elVsS2tYcWhyZ1J6V0g1UEJoNEdjd0hqa0JFTTQ4dXVOQS96bUgNCiBCRnZSc0Q1ZVBuY0lsN nM2ZHgwOXZnPT0NCg==</SwSec:CipherKey> <SwSec:CryptoProtocol>4.0:3.0</SwSec:CryptoProtocol> </SwSec:CryptoInternal> <SwSec:CryptoDescriptor> <SwSec:MemberRef>RequestPayload</SwSec:MemberRef> <SwSec:MemberRef>RequestHeader</SwSec:MemberRef> <SwSec:MemberRef>RequestDescriptor.SwiftRequestRef</SwSec:MemberRef> <SwSec:SignDN>cn=rma2,o=saadbebb,o=swift</SwSec:SignDN> <SwSec:CertPolicyId>1.3.21.6.2</SwSec:CertPolicyId> </SwSec:CryptoDescriptor> </Saa:AuthValue> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute /> </Saa:NetworkAttribute> <Saa:SecurityAttribute> <Saa:SWIFTNetSecurityAttribute> <Saa:SignerDN>cn=rma2,o=saadbebb,o=swift</Saa:SignerDN> </Saa:SWIFTNetSecurityAttribute> </Saa:SecurityAttribute> <Saa:MessageOrigin> <Saa:CBTApplication>SwiftnetInterface</Saa:CBTApplication> </Saa:MessageOrigin> <Saa:CBTRoutingInfo>SMQS_To_MQSeries</Saa:CBTRoutingInfo> <Saa:DuplEmission>false</Saa:DuplEmission> </Saa:MessageLPI> <Saa:MessageTPI> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkPriority>Normal</Saa:NetworkPriority> <Saa:NetworkSessionNr>003389</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000001560</Saa:NetworkSeqNr> <Saa:DuplCreation>PDE</Saa:DuplCreation> </Saa:MessageTPI> <Saa:MessageSRI> <Saa:UserReference>Sample-XMLv1-0609141402</Saa:UserReference> </Saa:MessageSRI> <Saa:MessageText> <AppHdr xmlns="urn:swift:xsd:$ahV10"> <MsgRef>Sample-XMLv1-0609141402</MsgRef> <CrDate>2006-09-14T02:02:11.414</CrDate> </AppHdr> <Document xmlns="urn:swift:xsd:swift.if.ia$setr.016.001.02"> <setr.016.001.02> <RltdRef> <Ref>Ref123-1</Ref> </RltdRef> <IndvOrdrDtlsRpt> <Sts>PACK</Sts> <OrdrRef>Ref123-1</OrdrRef> </IndvOrdrDtlsRpt> </setr.016.001.02> </Document> </Saa:MessageText> </Saa:Message> </Saa:DataPDU> D.5.1.5.2 Real time Message sent by an application to MQSA <?xml version="1.0" encoding="utf-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01"> <Saa:Message> <Saa:MessageFormat>MX</Saa:MessageFormat> <Saa:MessageSubFormat>Input</Saa:MessageSubFormat> <Saa:Sender> <Saa:X1>SAASBEBBXXX</Saa:X1> 468 System Management Guide Appendix D - Message Formats Used in AI </Saa:Sender> <Saa:Receiver> <Saa:FullName> <Saa:X1>SAATBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:MessageNature>FinancialNature</Saa:MessageNature> <Saa:MessageLPI> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saasbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>cn=beso,cn=tg229,o=saatbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.cashrepv1</Saa:Service> <Saa:RequestType>getaccount</Saa:RequestType> </Saa:SWIFTNetRequestAttribute> </Saa:NetworkAttribute> </Saa:MessageLPI> <Saa:MessageTPI> <Saa:NetworkPriority>Normal</Saa:NetworkPriority> </Saa:MessageTPI> <Saa:MessageSRI> <Saa:UserReference>REF-1-0609181711</Saa:UserReference> </Saa:MessageSRI> <Saa:MessageText> <Ah:AppHdr xmlns:Ah="urn:swift:xsd:$ahV10"> <Ah:MsgRef>SCRRQ01</Ah:MsgRef> <Ah:CrDate>2006-09-18T17:11:28.359</Ah:CrDate> </Ah:AppHdr> <Doc:Document xmlns:Doc="urn:swift:xsd:swift.cashrepv1$getaccount" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Doc:getaccount> <Doc:NstrAcctSchCrit> <Doc:AcctId> <Doc:DmstAcct>789DA123</Doc:DmstAcct> </Doc:AcctId> <Doc:BalTp>AVLB</Doc:BalTp> </Doc:NstrAcctSchCrit> <Doc:QryPrcg> <Doc:QryRef> <Doc:Ref>SCRRQ01</Doc:Ref> </Doc:QryRef> </Doc:QryPrcg> </Doc:getaccount> </Doc:Document> </Saa:MessageText> </Saa:Message> </Saa:DataPDU> Logical reply sent by MQSA to the application <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:LogicalReply> <Saa:SenderReference>ISAATBEBBXXXMX REF-1-0609181711</Saa:SenderReference> <Saa:SuccessIndication>true</Saa:SuccessIndication> </Saa:LogicalReply> </Saa:DataPDU> 15 July 2011 469 Alliance Access 7.0.20 Transmission Report sent by MQSA to the application <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:xsd:saa.mxs.01" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:SenderReference>ISAATBEBBXXXMX REF-1-0609181711</Saa:SenderReference> <Saa:Report> <Saa:Addressee> <Saa:X1>SAATBEBBXXX</Saa:X1> </Saa:Addressee> <Saa:OrigMessageFields>NoOriginal</Saa:OrigMessageFields> <Saa:ReportLPI> <Saa:OrigSenderReference>QU1RIFFNLkJFV1gxMjQgIH1WEUUgAAYC </Saa:OrigSenderReference> <Saa:MessageOrigin> <Saa:CBTApplication>Other</Saa:CBTApplication> </Saa:MessageOrigin> <Saa:Modified>false</Saa:Modified> <Saa:ReportingApplication>SWIFTNet Interface</Saa:ReportingApplication> <Saa:DuplEmission>false</Saa:DuplEmission> </Saa:ReportLPI> <Saa:TransmissionReport> <Saa:Network>SwiftNetNetwork</Saa:Network> <Saa:NetworkAttribute> <Saa:SWIFTNetRequestAttribute> <Saa:RequestorDN>o=saasbebb,o=swift</Saa:RequestorDN> <Saa:ResponderDN>cn=beso,cn=tg229,o=saatbebb,o=swift</Saa:ResponderDN> <Saa:Service>swift.cashrepv1</Saa:Service> <Saa:RequestType>getaccount</Saa:RequestType> <Saa:SwiftRef>SWITCH90-2006-09-20T15:03:30.22745.2556517Z</Saa:SwiftRef> <Saa:SwiftRequestRef>SNL00229-2006-09-20T15:03:29.7900.000004Z </Saa:SwiftRequestRef> <Saa:CBTReference>9c2392bf-63d9-4a1c-bd27-a7c9d0c1b1b1</Saa:CBTReference> </Saa:SWIFTNetRequestAttribute> <Saa:SWIFTNetResponseAttribute> <Saa:ResponderDN>cn=beso,cn=tg229,o=saatbebb,o=swift</Saa:ResponderDN> <Saa:SwiftResponseRef>SNL00229-2006-09-20T15:03:31.5004.000005Z </Saa:SwiftResponseRef> <Saa:AuthResult>Success</Saa:AuthResult> <Saa:AuthValue> <SwSec:CryptoInternal> <SwSec:CipherKey>UEVNRkBQcm9jLVR5cGU6IDQsTUlDLU9OTFkNCkNvbnRlbnQtRG9tYWluOiBSR kM4MjINCkVudHJ1c3RGaWxlLVZlcnNpb246IDIuMA0KT3JpZ2luYXRvci1ETjogY249cm1hNCxvPXN hYXRiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDE5Mzg1MjINCk1JQy1JbmZvOiBTSEExLCBSU0EsD QogZEF4b3VROFRFbldNNW03T2VOczZDdC8vTjFzOU9tUlo0cTFPdWI4ZnppT2xIQS95RDJhc2h5L2l KU2VOcjBuYg0KIHpJUnV5M09LczJ1TUlxT2p3MnVKSEZvb0hKYmtQTUdPOGtIZG91clo4K0tVeGFHM E5QSWtCTVJKYlZ0alRVdGgNCiBVcEw1TUJlSE5wcGtuN09VY2FUenFMT1ZQSnZ4Z2NrRUt4d25CNzd 5THRuay83YlRMVFhRR3FOVks2N0ROVS9rDQogcHZWZlUwWGxxNVVQWGoxMTVvWndxUS9HVzVHcGMxb 1hBYXpWdVJMTTFpa054UHRXejg0Sm9iT0FTVlR1VjFQYw0KIG9nNmRmUkRySGtSZWt2elh1V0pzazR sQjFiWGYrOVpCWTF0aWNIUCtiaTd2akV5bDZ5Mk1Ca1dWWXVGVzJ4TWsNCiBjMTEzam5EQjhad255T 2kzMU5jV3ZBPT0NCg==</SwSec:CipherKey> <SwSec:CryptoProtocol>4.0:3.0</SwSec:CryptoProtocol> </SwSec:CryptoInternal> <SwSec:CryptoDescriptor> <SwSec:MemberRef>ResponsePayload</SwSec:MemberRef> <SwSec:MemberRef>ResponseHeader</SwSec:MemberRef> <SwSec:MemberRef>ResponseDescriptor.SwiftResponseRef</SwSec:MemberRef> <SwSec:SignDN>cn=rma4,o=saatbebb,o=swift</SwSec:SignDN> <SwSec:CertPolicyId>1.3.21.6.2</SwSec:CertPolicyId> </SwSec:CryptoDescriptor> </Saa:AuthValue> </Saa:SWIFTNetResponseAttribute> </Saa:NetworkAttribute> <Saa:NetworkSessionNr>000003</Saa:NetworkSessionNr> <Saa:NetworkSeqNr>000000002</Saa:NetworkSeqNr> <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus> 470 System Management Guide Appendix D - Message Formats Used in AI <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>060920170319</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <AckNack> <PseudoAckNack>{1:F21SAASBEBBAXXX000003000000002}{4:{177:0609201703} {451:0}{311:ACK}{108:REF-1-0609181711}}</PseudoAckNack> </AckNack> </Saa:Text> </Saa:Intervention> <Saa:Intervention> <Saa:IntvCategory>TransmissionResponse</Saa:IntvCategory> <Saa:CreationTime>060920170326</Saa:CreationTime> <Saa:ApplicationOrigin>SWIFTNet Interface</Saa:ApplicationOrigin> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Text> <Ah:AppHdr xmlns:Ah="urn:swift:xsd:$ahV10"> <Ah:MsgRef>ra01</Ah:MsgRef> <Ah:CrDate>2006-09-18T17:12:30</Ah:CrDate> </Ah:AppHdr> <Doc:Document xmlns:Doc="urn:swift:xsd:swift.cashrepv1$returnaccount" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Doc:returnaccount> <Doc:QryRef> <Doc:Ref>SCRRQ01</Doc:Ref> </Doc:QryRef> <Doc:RtrRef> <Doc:Ref>RS01</Doc:Ref> </Doc:RtrRef> <Doc:Accts> <Doc:AcctRpt> <Doc:AcctId> <Doc:DmstAcct>789DA123</Doc:DmstAcct> </Doc:AcctId> <Doc:Acct> <Doc:Ccy>EUR</Doc:Ccy> <Doc:Bal> <Doc:Amt>99733.03</Doc:Amt> <Doc:CdtDbtInd>CRDT</Doc:CdtDbtInd> <Doc:ValDt> <Doc:Dt>2006-09-18</Doc:Dt> </Doc:ValDt> <Doc:Tp>AVLB</Doc:Tp> </Doc:Bal> </Doc:Acct> </Doc:AcctRpt> </Doc:Accts> </Doc:returnaccount> </Doc:Document> </Saa:Text> </Saa:Intervention> </Saa:Interventions> </Saa:TransmissionReport> </Saa:Report> </Saa:DataPDU> D.5.2 XML Format 2 Introduction The following sections describe the format of the Protocol Data Units (PDUs) exchanged between Alliance Access and the application. 15 July 2011 471 Alliance Access 7.0.20 Examples of Message Formats You can find examples of the XML version 1 message format in files Samples_v2.tar.Z in the following directory: • Windows: %alliance%\SWIFT\SERVER\MXS\batch_examples • UNIX: $ALLIANCE/Mxs/batch_examples D.5.2.1 New Format Changes D.5.2.1.1 Versioning Summary Since Alliance Access 6.2, a new approach to the versioning of the XML format is used for message exchange with back-office applications. In addition to the existing versioning of an XML schema, several revisions of the same version can exist. Taking into account the consequent revisions, the existing XML version 2.0 evolves as 2.0.1, 2.0.2, and so on. D.5.2.1.2 Schema Definition Changes in the definition of the XML v2 schema for revisions greater than zero • The version element is added to the schema definition for information purposes (the element is not used for format validation). Specifically, xs:schema:version element is added, indicating the revision of the schema. For example, for revision 2.0.1, the schema definition is (changes are in bold): <xs:schema version="2.0.1" elementFormDefault="qualified" xmlns="urn:swift:saa:xsd:saa.2.0" xmlns:xs=http://www.w3.org/2001/XMLSchema targetNamespace="urn:swift:saa:xsd:saa.2.0"> • The DataPDU:Revision element is added to the definition of DataPDU type. The presence of the Revision element is mandatory for the revisions greater than zero. Absence of the Revision element indicates that the document has revision 0 ("zero"). For example, for revision 2.0.1 the definition of the DataPDU type is as follows (changes are in bold): <xs:complexType name="DataPDU"> <xs:sequence> <xs:element name="Revision" type="SWString" fixed="2.0.1"/> <xs:element name="Header" type="Header" /> <xs:element name="Body" type="SwAny" minOccurs="0" /> </xs:sequence> </xs:complexType> The schema file name contains the revision number, if applicable. D.5.2.1.3 Changes in Revision 2.0.1 Overview This section provides a brief overview of the changes to the data element in revision 2.0.1. 472 System Management Guide Appendix D - Message Formats Used in AI Changes to the data element Message The format sub-element of Message can accept the value "AnyXML". AnyXML format messages can be sent and received by back-office applications, providing they are well-formed XML documents. No special licence option is required to process messages using this format. RoutingCode available for all instances The RoutingCode element in the InterfaceInfo data element is available for all types of message instances. AddressInfo can contain X as Sender The BIC12 in the AddressInfo data element can contain the value "X' as the 9th character of the logical terminal Terminal Code. SAAInfo added to data elements A data element, SAAInfo, of the type SAAInfo has been added to the following data elements: • Message • DeliveryNotification • HistoryReport • TransmissionReport • DeliveryReport • MessageStatus New Auxiliary type SAAInfo An auxiliary type, SAAInfo, has been added for use with the MQ Host Adapter: Element Description Type From To InstanceName The instance name of the Alliance Access that sends the message to a back-office application. It is followed by "/" and the exit point where the message was processed, or the queue to which the message was routed. From: the value is ignored String O M UserName The OS user that runs the Alliance Access server. From: the value is ignored String O M Unit The Alliance Access Unit to which the message belongs. From: the value is ignored String O M Changes to data sub-element of InterfaceInfo Element Description Type From To RoutingCode Information which is used for routing inAlliance Access. The code entered here is visible through the routing keyword 'Routing_code' (see "RoutingInstruction"). String O O 15 July 2011 473 Alliance Access 7.0.20 Element Description Type From To The limitation that only an Original instance or Copy instance can have this field has been removed. Any instance type can contain this element. The limitation that only Original or Copy message instances can have the RoutingCode field present is removed. The field can be optionally present for any type of message instance. Changes to sub-element SWIFTNetNetworkInfo Request type has been added for TARGET2 standard support: Changes to sub-element SWIFTNetNetworkInfo Element Description Type From To RequestType Contains the Request Type of the message. If not present, then the request type is assumed to be the same as the message identifier String O O D.5.2.1.4 Changes in Revision 2.0.2 Overview This section provides a brief overview of the changes to the data elements in revision 2.0.2. Changes to the data element Message The sub-element FileLogicalName has been added to support FileAct. The Format element can now have the value "File". The length of the SenderReference element is increased from 50 to 70 to accommodate the UMID + suffix. In the NetworkInfo element, the IsNotificationRequested sub-element can also be used for RealTime FileAct. In the InterfaceInfo element, the ProductInfo sub-element has been added to support the ProductList element. In the SWIFTNetSecurityInfo element, the FileDigestAlgorithm and FileDigestValue subelements have been added to support FileAct. In the SWIFTNetNetworkInfo element: • The SnFDeliveryTime sub-element has been added • To support the payload attributes, the sub-elements PayloadAttributes and ResponsePayloadAttributes have been added • To support FileAct, the following sub-elements have been added: CreationTime, IsCopyRequested, IsAuthNotificationRequested, CopyInfo, TransferRef, SnFTransferRef, TransferDescription, TransferInfo, FileDescription, FileInfo, HeaderInfo, NotificationResponderDN, NotificationRequestType, FileStartTime, FileEndTime. • To support the Overdue Warning feature of SWIFTNet 6.3, the OverdueWarningTime and OverdueWarningDelay sub-elements have been added. 474 System Management Guide Appendix D - Message Formats Used in AI Changes to the data element SessionStatus The sub-elements AcceptedFromMessagePartner, RejectedFromMessagePartner, AcceptedToMessagePartner, and RejectedToMessagePartner have been added, in relation to the introduction of the SOAP host adapter. The Format element can now have the value "File". The length of the Sender element is increased from 50 to 70 to accommodate the UMID + suffix. New Auxiliary type PayloadAttribute Element Description Type From To Name Name of the attribute associated to the payload of the SWIFTNet request, or response. String M M Value Value of the attribute associated to the payload of the SWIFTNet request, or response. String M M From To O O New Auxiliary type PayloadAttributeList Element Description Type PayloadAttribute The list of occurrences of the name, and value of an attribute. PayloadAttribute [1..N] New Auxiliary type Product Element Description Type From To VendorName Name of the vendor of the back-office application. String O O ProductName Name of the back-office application. String O O ProductVersion Version of the back-office application. String O O Type From To O O From To New Auxiliary type ProductList Element Description Product The list of occurrences of the VendorName, Product [0..3] ProductName, and ProductVersion. New Auxiliary type Digest Element Description Type DigestRef Identification of a digest. DigestRef M M DigestValue Value of a digest identified by DigestRef. DigestValue [0..1] O O From To O O New Auxiliary type DigestList Element Description Type Digest The list of occurrences of the Digest. Digest [1..8] 15 July 2011 475 Alliance Access 7.0.20 D.5.2.1.5 Changes in Revision 2.0.3 Overview This section provides a brief overview of the changes to the data elements in revision 2.0.3. Changes to the data element Message In the SWIFTNetNetworkInfo element: • The following sub-elements have been added to support the message and file distribution feature: – RecipientList – IsRecipientListPublic – DistributionInfo • The ThirdPartyList sub-element has been added to support the message and file dynamic copy feature. New Auxiliary type RecipientList Element Description Type RecipientDN The DN which identifies the recipient for the distribution of a message or file. RecipientDN [1..1000] From To O O From To O O New Auxiliary type ThirdPartyList Element Description Type ThirdPartyDN The DN which identifies the third party for the copy of a message or file. ThirdPartyDN [1..30] D.5.2.2 Protocol Data Units Description The application and Alliance Access exchange PDUs that are sequences of bytes with the following structure: Prefix Length Signature DataPDU • Prefix (1 byte): the character 0x1f. • Length (6 bytes): length (in bytes) of the Signature and DataPDU fields: this length is base-10 encoded as six ASCII characters, and is left-padded with zeros, if needed. • Signature (24 bytes): signature computed on the DataPDU using the HMAC-SHA256 algorithm, base-64 encoded (see "Computing the Signature of a DataPDU"). This signature authenticating the originator of the DataPDU (the application or Alliance Access) and guarantees the integrity of the DataPDU. This action is referred to as local authentication (LAU). If Alliance Access is configured to not require LAU, then the field must contain NULL characters. • DataPDU: XML structure containing the information relevant for processing (message or report) encoded in UTF-8 format. 476 System Management Guide Appendix D - Message Formats Used in AI The first byte of this field must be the character, < (0x3C). A byte-order marker is not supported. The structure of the DataPDU is described in the rest of this section. A DataPDU field has an overall XML structure that looks like: <?xml version="1.0" encoding="utf-8"?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0"> ... </Saa:DataPDU> A DataPDU field that Alliance Access sends to the application may contain structured data that is received from SWIFTNet. Therefore, the field may contain the following additional namespace declarations: xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt". xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec" The signature is computed on the complete DataPDU field, that includes the string <?xml version="1.0" encoding="utf-8"?>. The XML representation must not be altered between the signature computation and the verification. The namespace includes a version number (2.0). D.5.2.3 Structure of the DataPDU Introduction This section describes the various XML elements that can be present in the DataPDU field. The description uses a table format. The corresponding schema is located in the following directory in the Alliance Access release tree: On Windows: \MXS\xsd\SAA_XML_v2_0.xsd On UNIX: /MXS/xsd/SAA_XML_v2_0.xsd The columns "From" and "To" indicate whether the element is mandatory ('M'), optional ('O'), or not applicable ('--') for the corresponding direction of a message or report exchange. The directions are defined as follows: • "From": from the application to Alliance Access • "To": to the application from Alliance Access. D.5.2.3.1 DataPDU DataPDU elements Element Description Type From To Revision The revision to a version of an XML schema. Absence of the Revision element indicates that the document has revision 0 ("zero") String M(2) M Header Contains all information relevant to the processing of Alliance Access. Header M M 15 July 2011 477 Alliance Access 7.0.20 Element Description Type Body Contains the message "text". Present in a DataPDU carrying either a message, a delivery notification, or a report that includes the original message. For an MX message: this element contains the Application Header (if required(1)) and the Business Document as defined in the Solutions documentation. No encoding is required since these structures contain XML data. For an MT message: this element contains the FIN block 4, base-64 encoded (because this block does not contain XML data)(3). Any From To M O (1) If an Application Header is required, then the schema of the Application Header for each Standard that is part of a Solution is listed in the Implementor section of the Standards Handbook for that specific SWIFTStandard. (2) Mandatory for revisions greater than zero. (3) Example: a FIN block 4 containing "{4:20:TRN MSG1000:79:MESSAGE TEXT}" is included as follows in the Body element "<CRLF>:20:TRN MSG1000<CRLF>:79:MESSAGE TEXT", base-64 encoded. The Header type is defined as a union of the following types: • Message: when the DataPDU carries a message sent by the application to Alliance Access or by Alliance Access to the application. • HistoryReport: when the DataPDU carries a report used by Alliance Access to send a History or Information Notification to the application. • TransmissionReport: when the DataPDU carries a report used by Alliance Access to send a Transmission Notification to the application. • DeliveryNotification: when the DataPDU carries a Delivery Notification sent by Alliance Access to the application. • DeliveryReport: when the DataPDU carries a report used by Alliance Access to send a reconciled Delivery Notification to the application. Alliance Access sends such a report only if the Traffic Reconciliation component of Alliance Access is used to reconcile Delivery Notifications with original messages. • MessageStatus: when the DataPDU carries the status of the message processing sent by Alliance Access to the application. In case of error, it contains an error code that indicates why the message was rejected by Alliance Access. • SessionStatus: when the DataPDU carries the status of a session sent by Alliance Access to the application. This is not applicable to MQSA. Element Description Type ( Message | See "Message" HistoryReport | TransmissionReport | 478 From To Message M M See "HistoryReport" HistoryReport -- M See "TransmissionReport" TransmissionReport -- M System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To DeliveryNotification | See "DeliveryNotification" DeliveryNotification -- M DeliveryReport | See "DeliveryReport" DeliveryReport -- M MessageStatus | See "MessageStatus" MessageStatus -- M SessionStatus ) See "SessionStatus" SessionStatus -- M Element Description Type From To SenderReference Reference provided by the application for String reconciliation (see "Message Reconciliation Scenario") of a DataPDU carrying a message with the corresponding report DataPDUs. Length is 70 characters. M M MessageIdentifier The identification of the message. String M M String M M D.5.2.3.2 Message Message elements For an MT message, the format is: fin|apc.<msgtype>[.<mug(1)>] For example, fin.103, fin.103.REMIT For an MX message, the format is: <bus. area>.<msg type>.<variant>.<version> For example, ifds.001.001.01 The MessageIdentifier is used as the Request Type of the InterAct or FileAct message. It corresponds to the namespace URI of the XML Document in the Body which has the following structure: urn-prefix:[[service name] $]MessageIdentifier Format The message format: • for an MT message: MT • for an MX message: MX • for an FpML message: FpML • for a File message: File • for any message in an XML format not included in a deployment package installed on Alliance Access: AnyXML 15 July 2011 479 Alliance Access 7.0.20 Element Description Note SubFormat Type From To Enumeration(2) O M This list is not exhaustive. New values may be introduced by new or updated deployment packages installed on Alliance Access. The message sub-format. Possible values are: • Input (default value) • Output Both values can be used for the "From" as well as the "To" direction. Sender The address of the message sender (see "AddressInfo"). AddressInfo M M Receiver The address of the message receiver (see "AddressInfo"). AddressInfo M M InterfaceInfo General information managed by Alliance Access (see "InterfaceInfo"). InterfaceInfo O O NetworkInfo Network-related information managed by Alliance Access (see "NetworkInfo"). NetworkInfo O/M(3) O SecurityInfo Security-related information managed by Alliance Access (see "SecurityInfo"). SecurityInfo O O SAAInfo Information about the Alliance Access instance that processes the message. SAAInfo O O FileLogicalName Logical name of the file (1 to 254 characters). String O O (1) Message User Group (2) When the type Enumeration is used, possible values are defined in the Description column. (3) Optional for an MT message, mandatory for an MX message (contains the Service). D.5.2.3.2.1 InterfaceInfo InterfaceInfo elements This structure contains all the network-related information managed by Alliance Access to process messages. Element Description Type From To UserReference The Message User Reference. For FIN, this corresponds to the MUR (field 108 of block 3). String O O String O O For SWIFTNet, this is the RequestRef (part of the InterAct RequestHeader). RoutingCode 480 Information to influence routing in Alliance Access. The code entered here is visible System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To Enumeration O -- through the routing keyword 'Routing_code' (see "RoutingInstruction"). ValidationLevel Requested message validation level. Possible values are: • None • Minimum Extract routing keywords from message text • Intermediate MT messages: Minimum + syntax validation MX messages: same as Minimum • Maximum Same as Intermediate If specified, has precedence over the Alliance Access configuration. IsModificationAllowed If set to true, then the message can be modified using the Message Modification application in Alliance Access or using Alliance Messenger (available on Alliance Web Platform). If set to false, then the message cannot be changed. Default value: as defined in the Alliance Access configuration. Boolean O -- RoutingInstruction Specifies where the message has to be created in Alliance Access (see "RoutingInstruction"). If specified, has precedence over the Alliance Access message partner configuration. Currently not applicable to MQSA: if present, it is ignored. RoutingInstruction O -- MessageCreator The Alliance Access component that created the message. Enumeration O O Possible values are: • ApplicationInterface • SWIFTNetInterface • FINInterface • Workstation • Messenger • Other 15 July 2011 481 Alliance Access 7.0.20 Element Description Type From To Enumeration O M Enumeration O M ProductList O O Only present for Original or Copy instances. From: the value is ignored(1). MessageContext The Alliance Access message instance type: • Original • Copy • Report From: the value is ignored(1). MessageNature The message nature. Possible values are: • Financial • Text • Network • Security • Service For MX messages, the value Financial must be used. From: only for Output messages. ProductInfo Information about the back-office applications sending the messages. (1) This field is optional in the From direction to allow a DataPDU received from Alliance Access to be sent to Alliance Access again without changing it. However, Alliance Access ignores its value. D.5.2.3.2.2 NetworkInfo NetworkInfo elements This structure contains all the network-related information managed by Alliance Access to process messages. Element Description Type From To Priority The Network priority. Enumeration O M Boolean O M Possible values are: • Normal • Urgent • System (FIN only) Default value: Normal. IsPossibleDuplicate 482 From: the application indicates that the message is a PDE (Possible Duplicate Emission). System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To To: Alliance Access indicates that the message has possibly been delivered already to the application or that it has been received with a PDE/PDM indication. In the latter case, the element DuplicateHistory is also present. Default value: false. DuplicateHistory History details of the possible duplicates (PDEs and PDMs). From: for Output messages only. PDEPDM [1..N] O O IsNotificationRequested Indicates whether a positive delivery notification is requested. Can also be used for Real-time FileAct. Default value: false. Not present for Output messages. Boolean O O Service The SWIFTNet service name. Mandatory for SWIFTNet. For FIN, the value must be 'swift.fin' when specified. String O M Network The network over which the message has been transmitted. Enumeration O M Possible values are: • Application • SWIFTNet • FIN • Other From: for Output messages only. SessionNr The network session number. From: for Output messages only. Integer O M SeqNr The network sequence number. From: for Output messages only. Integer O M ( SWIFTNetNetworkInfo | SWIFTNet-specific network information (see "SWIFTNetNetworkInfo"). SWIFTNetNetworkInfo O O FINNetworkInfo ) FIN-specific network information (see "FINNetworkInfo"). FINNetworkInfo O O D.5.2.3.2.2.1 SWIFTNetNetworkInfo SWIFTNetNetworkInfo elements Element Description Type From To RequestType Contains the Request Type of the message. If not present, then the request type is assumed to be the same as the message identifier. String O O 15 July 2011 483 Alliance Access 7.0.20 Element Description Type From To SWIFTRef The reference generated by the central SWIFT infrastructure. Always present for Output messages, Transmission Reports with delivery status Acked, and Delivery Reports. String O O String O O Format: SWITCHid-YYYY-MMDDTHH:MM:SS.procid.digitsZ Where: • SWITCHid is the ID of the switch that generated the reference • procid is the process ID of the process that created the reference • digits makes the reference unique within a given second • the timestamp is the time of generation of the reference in UTC From: for Output messages only. SNLRef The reference generated by the emitting SWIFTNet Link. Always present for Output messages, Transmission Reports with delivery status Acked, and Delivery Reports. Format: SNLid-YYYY-MMDDTHH:MM:SS.procid.digitsZ Where SNLid is the ID of the SWIFTNet Link that generated the reference. The other parts are identical to the format of "SWIFTRef". From: for Output messages only. Reference The reference generated by Alliance Access (for messages sent) or by the correspondent application (for messages received). From: for Output messages only. String O O SNLEndPoint The SWIFTNet Link endpoint. Real-time messages only. From: for Output messages only. String O O SnFQueueName The store-and-forward queue name. Store-and-forward messages only. From: for Output messages only. String O O SnFInputTime SWIFTNet storage location and time of a store-and-forward request (UTC). String O O Format: nnnn:YYYY-MM-DDTHH:MM:SS 484 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To String O O String O O Where nnnn is the SWIFT internal storage identifier. SnFDeliveryTime The time (UTC) when the message was acknowledged by the receiver. Format: YYYY-MM-DDTHH:MM:SSZ CreationTime The time (local system time in UTC) when the initial message request was created. Format: YYYY-MM-DDTHH:MM:SSZ The CreationTime is only meaningful for an output message. ValidationDescriptor MVal processing result. From: for Output messages only. Any O O ResponseResponderDN The responder DN of the response. Real-time messages only. String -- O ResponseSWIFTRef The response reference generated by the central SWIFT infrastructure. String -- O String -- O The reference generated by the responding String application. Format: see "SwiftReference" in SWIFTNetNetworkInfo. -- O Format: SWITCHid-YYYY-MM-DDTHH: MM:SS.procid.digitsZ Where: • SWITCHid is the ID of the switch that generated the reference • procid is the process ID of the process that created the reference • digits makes the reference unique within a given second • the timestamp is the time of generation of the reference in UTC Real-time messages only. ResponseSNLRef The reference generated by the SWIFTNet Link of the responding application. Format: SNLid-YYYY-MM-DDTHH: MM:SS.procid.digitsZ Where SNLid is the ID of the SWIFTNet Link that generated the reference. The other parts are identical to the format of "SWIFTRef". Real-time messages only. ResponseReference 15 July 2011 485 Alliance Access 7.0.20 Element Description Type From To Real-time messages only. IsPossibleDuplicateRespon Indicates whether the response is a se possible duplicate. Real-time messages only. Default value: false. Boolean -- O ResponseValidationDescri ptor MVal processing result of the response. Real-time messages only. Any -- O PayloadAttributes List of names and values associated to attributes of SWIFTNet message requests. Example: the attribute "type" on the SwInt:RequestPayload. PayloadAttributeList - O ResponsePayloadAttribute s List of names and values associated with attributes of SWIFTNet message responses. Example: the attribute "type" on the SwInt:ResponsePayload. PayloadAttributeList - O IsCopyRequested True when the SWIFTNet copy feature is Boolean optional for that service and a copy must be made. When absent, a copy is only made when the copy feature is defined as mandatory for the service. If the copy service is defined as mandatory, then this value cannot be False. O O IsAuthNotificationRequeste d Request a positive Authorisation Notification for Y-Copy service. Boolean O - CopyInfo Provides copy-processing related information. From: for Output messages only. Sw:Copy O O TransferRef The unique reference of the file transfer. From: for Output messages only. String O O StoredTransferRef The unique reference of the file transfer notification. For Reception only on store and forward. String - O OrigSnFRef Present if a notification relates to a copy. For Reception only on store and forward. String - O TransferDescription Information about the file transfer (free text). String O O TransferInfo Structured data that the receiver can use for automatic processing of the file transfer. String O O FileDescription Information about the file (free text). String O O FileInfo Structured data that the receiver can use for automatic processing of the file. String O O HeaderInfo Sw:HeaderInfo in end-to-end control data. Sometimes this element is mandatory. See "The HeaderInfo element" on page 487. XML O O NotificationResponderDN Delivery Notification Receiver DN (for Realtime FileAct). String O O 486 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To Not present for Output messages. NotificationRequestType Delivery Notification Request Type (for Real-time FileAct). String O O FileStartTime The time when the file transfer was started. From: for Output messages only. String O O String O O Time and date in UTC after which store String and forward has to generate an overdue warning if the message/file remains undelivered. Cannot be in the past or more than 14 days in the future. If present, no OverdueWarningDelay can be specified. O O Format: YYYYMMDDHHMMSS FileEndTime The time when the file transfer ended. From: for Output messages only. Format: YYYYMMDDHHMMSS OverdueWarningTime Format: YYYY-MM-DDTHH:MM:SSZ OverdueWarningDelay Number of minutes after which store and forward has to generate an overdue warning if the message/file remains undelivered. Minimum 5, maximum 1440 (1 day). If present, no OverdueWarningTime can be specified. String O O RecipientList The list of recipients to which the message/ file must be distributed. The content of the element RecipientList of an input message is placed in the element RecipientDNList of the related output message. The element RecipientDNList is included in the element DistributionInfo. RecipientList O -- ThirdPartyList The list of third party recipients to which the ThirdPartyList message or file must be copied in case of dynamic T- or Y-Copy. O O IsRecipientListPublic This element, when absent or equal to TRUE, indicates that the RecipientList is public and has to be forwarded to all Recipients. Boolean O -- DistributionInfo Distribution information provided to the recipient of a distributed message or file. From: for output messages only. Sw:DistributionInfo O O The HeaderInfo element Sometimes, the HeaderInfo element is mandatory. The Application Service Profile defines the mandatory elements for a service, or for a particular solution. You can specify these key 15 July 2011 487 Alliance Access 7.0.20 mandatory elements in the HeaderInfo element and therefore, the content of HeaderInfo differs for each service. The HeaderInfo is placed in the FileAct header and verified by the SWIFTNet central system or back-office application based on the service that uses it. The SWIFTNet central system verifies the presence, syntax and semantic meaning of the elements. If the verification fails, then the message is rejected. The FileAct Header information is mandated for the following services that SWIFT administers: Service swift.remit.fast Request Types All swift.remit.fast!p General FileAct Header Documentation Standards MX - General Information Guide(1) swift.remit.fast!x Solution-specific FileAct Header requirements Workers' Remittances Standards MX Message Implementation Guidelines(1) (1) This guide is available through the Documentation site on www.swift.com Note SWIFTNet Copy Services can copy the content of the HeaderInfo element and send it to a Copy destination. The following connection methods support the use of the HeaderInfo element: • "File Transfer" on page 564 • "SOAP" on page 587 • "WebSphere MQ" on page 616 D.5.2.3.2.2.2 FINNetworkInfo FINNetworkInfo elements Element Description Type From To UserPriority FIN User Header field 113; Banking Priority String O O CopyService Value-added service ID String O O The syntax version (for example, 0505). String O M MessageSyntaxVersion From: Output messages only. IsRetrieved Indicates whether the message is a retrieved message. Default value: false. Output messages only. Boolean O O ReleaseInfo FIN User Header field 115: information from Central Institution to the receiver of payment message. Output messages only. String O O ValidationIdentifier FIN User Header field 119: Validation Identifier Cannot be present if the MessageIdentifier contains the optional Message User Group (see "Message"). String O O CorrespondentInputRefe rence The sender logical terminal, session, and sequence numbers used by the correspondent to send the message. String O O 488 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To CorrespondentInputTime Time and date the message was sent by the correspondent. Output messages only. String O O LocalOutputTime Time and date the message was received by this interface. Output messages only. String O O SystemOriginated SYS trailer Output messages only. String O O DelayedMessage Delayed Message trailer Output messages only. String O O FINUserHeader Full FIN user header (block 3 of FIN message) String O O Output messages only. D.5.2.3.2.3 SecurityInfo SecurityInfo elements This structure contains all the security-related information managed by Alliance Access to process messages. Element Description Type From To IsSigningRequested Indicates whether signing of the message is required upon emission: Boolean O -- Enumeration O O SWIFTNetSecurityInfo O O • SWIFTNet: if specified, overrides the Alliance Access emission profile configuration. • FIN: if specified, the value is ignored. RMAResult The result of the Authorisation verification. Possible values are: • Success • Bypassed • NoRecord • NotEnabled • InvalidPeriod • Unauthorised Not present when message is not subject to RMA authorisation. From: Output messages only. ( SWIFTNetSecurityInfo | 15 July 2011 SWIFTNet-specific security information (see "SWIFTNetSecurityInfo"). 489 Alliance Access 7.0.20 Element Description Type FINSecurityInfo ) FIN-specific security information (see "FINSecurityInfo"). FINSecurityInfo From To O O From To D.5.2.3.2.3.1 SWIFTNetSecurityInfo SWIFTNetSecurityInfo elements Element Description Type IsNRRequested Indicates whether non-repudiation is requested. Default value: as defined in the Alliance Access emission profile configuration. Boolean O -- SignerDN The Signer DN. From: Output messages only. String O O NRType Non-repudiation processing information (Type). Enumeration O O Possible values are: • SvcOpt • SvcMand From: Output messages only. NRWarning Non-repudiation processing information (Warning). String O O SignatureResult The signature result. Enumeration O O Possible values are: • Success • Bypassed • Failed From: Output messages only. SignatureValue The signature value. From: Output messages only. Any O O ResponseNRType Non-repudiation processing information (Type) for the response. Enumeration -- O Possible values are: • SvcOpt • SvcMand Real-time messages only. ResponseNRWarning Non-repudiation processing information for the response (Warning). Real-time messages only. String -- O ResponseSignatureResult The signature result for the response. Enumeration -- O 490 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To Possible values are: • Success • Bypassed • Failed Real-time messages only. ResponseSignatureValue The signature value for the response. Real-time messages only. Any -- O FileDigestAlgorithm Name of the file digest algorithm ("SHA-1"" or "SHA-256"). 1 to 20 characters. String O O FileDigestValue Value of the file digest. 1 to 50 characters. String O O DigestList Allows to override the usual digest(s) used for MX and File messages. Optional and composed of up to 8 digests. DigestList O O O O From To Composed of 2 elements: • DigestRef (mandatory) • DigestValue (optional). ThirdPartySignerDn The Third Party Signer DN if the digest on String Sw:ThirdPartyToSenderInfo is received in a second signature. From: for Output messages only. D.5.2.3.2.3.2 FINSecurityInfo FINSecurityInfo elements Element Description Type ChecksumResult The result of the FIN checksum validation. Enumeration O O Possible values are: • Success • Failed From: Output messages only. ChecksumValue The value of the FIN checksum. From: Output messages only. String O O PACResult The result of the PAC verification. Enumeration O O Possible values are: • Success • SuccessFuture • SuccessOld • Bypassed 15 July 2011 491 Alliance Access 7.0.20 Element Description Type From To String O O Enumeration O O String O O O O • NoKey • Failed • InvalidDigest • InvalidSignerDN • InvalidCertPolicyID From: Output messages only. PACValue PAC value: • From: MT 097 Input message (FINCopy server) and Output messages. • To: Present if the message is subject to FINCopy. Depending on the Alliance Access configuration for message partner or MQSA, the value can be a "dummy" value (00000000). MACResult The result of the MAC verification. Possible values are: • Success • SuccessFuture • SuccessOld • Bypassed • NoKey • Failed • InvalidDigest • InvalidSignerDN • InvalidCertPolicyID From: Output messages only. MACValue MAC value. Present if the message requires authentication. Depending on the Alliance Access configuration for message partner or MQSA, the value can be a "dummy" value (00000000). From: Output messages only. MACSignatureValue Signature of the MAC equivalent digest Any (also includes the PAC1(1) equivalent digest if required). From: Output messages only. 492 System Management Guide Appendix D - Message Formats Used in AI Element Description PAC2SignatureValue Type PAC2(2) Signature of the equivalent digest. From: Output messages only. Any From To O O (1) Used for authentication between the Sender of the message and the Central Institution. (2) Used for authentication between the Central Institution and the Receiver of the message. D.5.2.3.3 HistoryReport HistoryReport elements Alliance Access uses a HistoryReport to send a "History Notification" or "Information Notification" to the application. The Print connection method supports the transmission of a history notification of both input and output messages. The connection method that uses XML version 2 supports the transmission of a history notification only for input messages. For a History Notification, the report contains a list of all interventions belonging to the related instance, up to the routing point where the History Notification was created. For an Information Notification, the report only contains the interventions that were created at the routing point where the Information Notification was created. Element Description Type From To SenderReference SenderReference that the application has provided when sending the corresponding message. String -- M OriginalInstanceAddressee The address of the receiver of the original instance (see "AddressFullName"). AddressFullName -- M ReportingApplication The Alliance Access component that generated the report Enumeration -- M Possible values are: • ApplicationInterface • FINInterface • SWIFTNetInterface • TrafficReconciliation • Other SAAInfo Information about the Alliance Access instance that processes the message. SAAInfo - O Interventions The list of interventions. HistoryIntervention [1..N] -- M IsRelatedInstanceOriginal Indicates whether this report is about an Original or a Copy instance: Boolean -- M • true: RelatedInstanceAddressee is not present 15 July 2011 493 Alliance Access 7.0.20 Element Description Type From To • false: RelatedInstanceAddressee is possibly present RelatedInstanceAddressee If this report concerns a Copy instance, then this field contains the address of the receiver of the Copy (see "AddressFullName"). Present if the element IsRelatedInstanceOriginal (previous element) has a value of false. AddressFullName -- O MessageCreator The Alliance Access component that created the message. Enumeration -- M Possible values are: • ApplicationInterface • SWIFTNetInterface • FINInterface • Workstation • Messenger • Other IsMessageModified Indicates whether the message has been modified within Alliance Access. Boolean -- M MessageFields The level of detail that Alliance Access provides about the original Message (next element), as defined in the Alliance Access configuration. Enumeration -- M Possible values are: • NoOriginal The next element Message will not be present. Used when the Message Partner or queue profile is configured to never send the original message for notifications. When the Message Partner or queue profile is configured to include the original message in the report, the following values allow defining the elements of the original message that are present in the next element Message: • MinimumInfo The next element Message contains the element Header, but not the element Body. The Header will not contain the InterfaceInfo, NetworkInfo, SecurityInfo elements. 494 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To -- O Corresponds to a configuration specifying "Minimum Info". • HeaderOnly The next element Message contains the complete element Header but not the element Body. Corresponds to a configuration specifying "Headers Only" • HeaderAndBody The next element Message contains its complete structure. Corresponds to a configuration specifying "Complete Text" or "Expanded". Message The original Message (see "Message"). Message The content of this element depends on the value of MessageFields. D.5.2.3.4 TransmissionReport TransmissionReport elements Alliance Access uses a TransmissionReport to send a Transmission Notification to the application. The report contains an intervention of type TransmissionReport, and optionally, an intervention of type TransmissionResponse. A transmission response can appear for real-time input messages for which the real-time server generates a business response. A Transmission Notification instance is created by the Alliance Access network interface components (for example, SWIFT Interface for MT, SWIFTNet Interface for MX) when an attempt is made to transmit the message. Element Description Type From To SenderReference SenderReference that has been provided by the application when sending the corresponding message. String -- M ReconciliationInfo Used by the application to reconcile a Delivery Notification with the original message through a Report (see "Message Reconciliation Scenario"). String -- O Enumeration -- M Possible values are: • MIR of the message for FIN • SwiftRef of the message for SWIFTNet Only present when element NetworkDeliveryStatus has value NetworkAcked. NetworkDeliveryStatus The network delivery status. Possible values are: • NetworkAcked 15 July 2011 495 Alliance Access 7.0.20 Element Description Type From To • NetworkNacked • NetworkRejectedLocally The message has been rejected by Alliance Access before emission. • NetworkAborted The message emission has been aborted due to a communication error or a user abort of the session. • NetworkTimedOut The acknowledgement for the message was not received within the allowed time (SWIFTNet only). • NetworkWaitingAck Transient state. Unless the Alliance Access routing is configured to do so, the last 3 values are not reported to the application. OriginalInstanceAddressee The address of the receiver of the original instance (see "AddressFullName"). AddressFullName -- M ReportingApplication The Alliance Access component that generated the report. Enumeration -- M Possible values are: • ApplicationInterface • FINInterface • SWIFTNetInterface • TrafficReconciliation • Other NetworkInfo Network-related information managed by Alliance Access (see "NetworkInfo"). NetworkInfo -- M SAAInfo Information about the Alliance Access instance that processes the message. SAAInfo - O Interventions The list of interventions. Intervention [1..N] -- M IsRelatedInstanceOriginal Indicates whether this report is about an Original or a Copy instance: Boolean -- M • true: RelatedInstanceAddressee is not present • false: RelatedInstanceAddressee is possibly present 496 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To RelatedInstanceAddressee If this report concerns a Copy instance, then this field contains the address of the receiver of the Copy (see "AddressFullName"). Present if the element IsRelatedInstanceOriginal (previous element) has a value of false. AddressFullName -- O MessageCreator The Alliance Access component that created the message. Enumeration -- M Possible values are: • ApplicationInterface • SWIFTNetInterface • FINInterface • Workstation • Messenger • Other IsMessageModified Indicates whether the message has been modified within Alliance Access. Boolean -- M MessageFields See the definition of MessageFields in "HistoryReport". Enumeration -- M Message The original Message (see "Message"). Message The content of this element depends on the value of MessageFields. -- O D.5.2.3.5 DeliveryNotification DeliveryNotification elements Alliance Access uses a DeliveryNotification to send a Delivery Notification to the application. The report contains an intervention of type DeliveryReport. Element Description Type From To ReconciliationInfo Reconciliation information. String - M Value: • MIR of the original message for FIN • SwiftRef of the original message for SWIFTNet. This element contains the information that the application requires, to reconcile the DeliveryNotification with the TransmissionReport (through the ReconciliationInfo element present in the TransmissionReport), then with the original Message (through the SenderReference element of the TransmissionReport and of the original Message). 15 July 2011 497 Alliance Access 7.0.20 Element Description Type From To Enumeration -- M String -- M See "Message Reconciliation Scenario" for an explanation of the reconciliation scenario. ReceiverDeliveryStatus The Delivery Notification status. Possible values are: • RcvDelivered • RcvAborted • RcvDelayedNak FIN: the message has been rejected by FIN and has not been received by the correspondent SWIFTNet store-and-forward: the message has been rejected by the correspondent. • RcvFCPReleased The message has been released by the Central Institution (FIN only). • RcvOverdue Can occur only when the related message had Priority set to Urgent. • RcvUnknown Can occur, for instance, when InterAct or FileAct messages are sent in the context of a distribution to several recipients. MessageIdentifier The identification of the message. For an MT message, the format is: fin|apc.<msgtype>[.<mug(1)>] For example, fin.103, fin.103.REMIT Otherwise, the value is the string "Delivery Notification". Receiver The address of the receiver of the Delivery Notification (see "AddressInfo"). FIN only. AddressInfo -- O InterfaceInfo General information managed by Alliance Access (see "InterfaceInfo"). InterfaceInfo -- O NetworkInfo Network-related information managed by Alliance Access (see "NetworkInfo"). NetworkInfo -- O SecurityInfo Security-related information managed by Alliance Access (see "SecurityInfo"). FIN only. SecurityInfo -- O 498 System Management Guide Appendix D - Message Formats Used in AI Element Description Type SAAInfo Information about the Alliance Access instance that processes the message. SAAInfo From To - O (1) Message User Group D.5.2.3.6 DeliveryReport DeliveryReport elements Alliance Access uses a DeliveryReport to send a Delivery Notification to the application when the Traffic Reconciliation component of Alliance Access is used. The report contains an intervention of type DeliveryReport. Element Description Type From To SenderReference SenderReference that the application has provided when sending the corresponding message. String -- M ReceiverDeliveryStatus The Delivery Notification status. String -- M Possible values are: • RcvDelivered • RcvAborted • RcvDelayedNak • RcvFCPReleased • RcvOverdue See "DeliveryNotification". OriginalInstanceAddressee The address of the receiver of the original instance (see "AddressFullName"). AddressFullName -- M ReportingApplication The Alliance Access component that generated the report. Enumeration -- M Possible values are: • ApplicationInterface • FINInterface • SWIFTNetInterface • TrafficReconciliation • Other NetworkInfo Network-related information managed by Alliance Access (see "NetworkInfo"). NetworkInfo -- M SAAInfo Information about the Alliance Access instance that processes the message. SAAInfo - O Interventions The list of interventions. Intervention [1..N] -- M IsRelatedInstanceOriginal Indicates whether this report is about an Original or a Copy instance Boolean -- M 15 July 2011 499 Alliance Access 7.0.20 Element Description Type From To Possible values are: • true: RelatedInstanceAddressee is not present • false: RelatedInstanceAddressee is possibly present RelatedInstanceAddressee If this report concerns a Copy instance, then this field contains the address of the receiver of the Copy (see "AddressFullName"). Present if the element IsRelatedInstanceOriginal has a value of false. AddressFullName -- O MessageCreator The Alliance Access component that created the message. Enumeration -- M Possible values are: • ApplicationInterface • SWIFTNetInterface • FINInterface • Workstation • Messenger • Other IsMessageModified Indicates whether the message has been modified within Alliance Access. Boolean -- M MessageFields See the definition of MessageFields in "HistoryReport". Enumeration -- M Message The original Message (see "Message"). Message The content of this element depends on the value of MessageFields. -- O D.5.2.3.7 MessageStatus MessageStatus elements Element Description Type From To SenderReference Sender reference that had been provided by the application when sending the corresponding Message. String -- O SeqNr The sequence number of the concerned DataPDU in the file. Not applicable to MQSA. Integer -- O IsSuccess Indicates the result of the processing of the DataPDU by Alliance Access: Boolean -- M • true if the DataPDU was processed successfully by Alliance Access 500 System Management Guide Appendix D - Message Formats Used in AI Element Description Type From To • false if an error occurred during the processing of the DataPDU. ErrorCode Code identifying the error. Only present if the element IsSuccess has value false. String -- O ErrorText Text associated with the error code. Only present if the element IsSuccess has value false. String -- O SAAInfo Information about the Alliance Access instance that processes the message. SAAInfo - O D.5.2.3.8 SessionStatus SessionStatus elements Not applicable to MQSA. Element Description Type From To MessagePartner The name of the message partner. String M M CreationTime Date and Time the SessionStatus DataPDU was generated. Format: 'YYYYMMDDHHMMSS' String M M SessionNr The session number. Integer M M InputFile The name of the input file. String -- O IsSuccess Indicates the result of the processing by Alliance Access: Boolean M M • false if the session was aborted by Alliance Access during the processing of the file (no PDU contained in the file has been processed by Alliance Access). • true otherwise. ErrorCode Code identifying the error. Only present if the element IsSuccess has a value of false. String O O ErrorText Text associated with the error code. Only present if the element IsSuccess has a value of false. String O O SessionDirection The direction of the message flow: String O O • FromMessagePartner: message from the message partner to Alliance Access. • ToMessagePartner: message to the message partner fromAlliance Access. • ToAndFromMessagePartner: message to the message partner from Alliance 15 July 2011 501 Alliance Access 7.0.20 Element Description Type From To Integer O O Integer O O AcceptedFromMessagePar The number of messages accepted by tner Alliance Access. Only present if the element IsSuccess has a value of true and for the SOAP connection method. Integer O O RejectedFromMessagePart The number of messages rejected by ner Alliance Access. Only present if the element IsSuccess has a value of true and for the SOAP connection method. Integer O O AcceptedToMessagePartn er The number of messages sent by Alliance Access and accepted by the message partner. Only present if the element IsSuccess has a value of true and for the SOAP connection method. Integer O O RejectedToMessagePartne The number of messages sent by Alliance r Access and rejected by the message partner. Only present if the element IsSuccess has a value of true and for the SOAP connection method. Integer O O Access and message from the message partner to Alliance Access. Only present for SOAP adapters. Accepted Depends of the SessionDirection setting: • FromMessagePartner: the number of messages accepted by Alliance Access. • ToMessagePartner: the number of messages sent by Alliance Access and accepted by the message partner. If the element SessionDirection is not present, then the number of messages accepted by Alliance Access. Rejected Depends of the SessionDirection setting: • FromMessagePartner: the number of messages rejected by Alliance Access. • ToMessagePartner: the number of messages sent by Alliance Access and accepted by the message partner. If the element SessionDirection is not present, then the number of messages rejected by Alliance Access. Only present if the element IsSuccess has a value of "true". 502 System Management Guide Appendix D - Message Formats Used in AI D.5.2.3.9 Auxiliary Types D.5.2.3.9.1 AddressInfo AddressInfo elements Element Description Type From To ( BIC12 | Sender: The first 9 characters identify the Sender logical terminal. "X" is accepted as 9th character in a BIC12. If the logical terminal is not defined in Alliance Access, then the message is rejected with an error (see "Error Codes"). Receiver: the 9th char must always be "X". FIN only. String M M Nickname | The correspondent nickname. Only for a Receiver address. FIN only. Currently not applicable to MQSA. String M -- DN ) The DN identifying the sender or receiver of the message. SWIFTNet only. If the FullName element (below) is not present, the DN content is used as follows to build the correspondent parts used for the correspondent lookup in Alliance Access. Example: DN = cn=name,ou=payment,o=bank,o=swift String M M AddressFullName O O • bank is mapped to a correspondent X1 part: the institution BIC11. The character X is added to obtain a string of 11 characters, that is, bankXXXXXXX • payment is mapped to a correspondent X2 part: the department or application name • name is mapped to a correspondent X3 part: if the correspondent type is Application, then it contains routing information. If the correspondent type is Individual, then it contains the last name. FullName 15 July 2011 Detailed address information (see "AddressFullName"). Alliance Access always sends this to the application if present in the Correspondent Information File. Cannot be specified if the element Nickname is present. 503 Alliance Access 7.0.20 D.5.2.3.9.2 AddressFullName AddressFullName elements Element Description Type From To X1 The correspondent X1 part: the Institution BIC11. String M M X2 The correspondent X2 part: Department or Application name. Present if correspondent is of type Department or Application or Individual. String O O X3 The correspondent X3 part: if the correspondent type is Application, then it contains routing information; if the correspondent type is Individual, then it contains the last name. Present if the correspondent is of type Application or Individual. String O O X4 The correspondent X4 part: the firstname. Present if the correspondent is of type Individual. String O O FinancialInstitution Name of the institution. String O O BranchInformation Branch information. String O O CityName City name. String O O Location Location. String O O CountryCode Country code. String O O Type From To M -- O -- D.5.2.3.9.3 RoutingInstruction RoutingInstruction elements Element Description RoutingFunction The routing function to be performed on the Enumeration message. Possible values are: • Route the target routing point is determined by the routing rules of Alliance Access • DisposeToRoutingPoint the target routing point is specified by the value of the next element • DisposeToRoutingStep the target routing point is specified by the value of the RoutingStep element RoutingPoint 504 The target routing point. Present if the element RoutingFunction has value "DisposeToRoutingPoint". String System Management Guide Appendix D - Message Formats Used in AI Element Description Type RoutingStep The requested message disposition state. The corresponding routing point name is listed between parentheses. Enumeration From To O -- Possible values are: • Verify (_MP_verification) • Authorise (_MP_authorisation) • Modify (_MP_mod_text) • ReadyToSend (based on the preferred network settings of the Receiver in the Alliance Access Correspondent Information File) Present if the element RoutingFunction has a value of "DisposeToRoutingStep". D.5.2.3.9.4 PDEPDM PDEPDM elements Element Description Type From To ( PDE | FIN only: the PDE value. String O M PDM ) FIN: the PDM value. SWIFTNet: the store and forward PDM history. String O M D.5.2.3.9.5 Intervention Intervention elements This type is only used in the elements of type TransmissionReport and DeliveryReport. Element Description Type From To IntvCategory Intervention category. Enumeration -- M String -- M Possible values are: • TransmissionReport present if TransmissionReport • DeliveryReport present if DeliveryReport • TransmissionResponse only present in TransmissionReport or HistoryReport for MX Input messages. CreationTime 15 July 2011 The intervention creation date and time. Format: "YYYYMMDDHHMMSS". 505 Alliance Access 7.0.20 Element Description Type From To OperatorOrigin The name of the operator that triggered the intervention creation. String -- M Contents The intervention contents. Any - M D.5.2.3.9.6 HistoryIntervention HistoryIntervention elements This type is only used in the element HistoryReport. The difference with the type Intervention (see "Intervention") is that the contents of the intervention (element Text) is passed as a String (escaped). The format of the intervention contents in a HistoryReport can indeed be a combination of free-format text and of XML. Element Description Type From To IntvCategory Intervention category. Enumeration -- M Possible values are: • TransmissionReport present if TransmissionReport • DeliveryReport present if DeliveryReport • TransmissionResponse only present in TransmissionReport or HistoryReport for MX Input messages • Security • Routing • MesgAsTransmitted • MesgAsReceived • MesgModified • Other CreationTime The intervention creation date and time. Format: "YYYYMMDDHHMMSS"'. String -- M OperatorOrigin The name of the operator that triggered the intervention creation. String -- M Text The intervention text. String -- M 506 System Management Guide Appendix D - Message Formats Used in AI D.5.2.3.9.7 SAAInfo SAAInfo elements The SAAInfo element is an optional element. However, if you do include it, then you must specify all of its sub-elements: Element Description Type From To InstanceName The instance name of the Alliance Access that sends the message to a back-office application. It is followed by "/" and the exit point where the message was processed, or the queue to which the message was routed. From: the value is ignored. String O M UserName The OS user that runs the Alliance Access server. From: the value is ignored. String O M Unit The Alliance Access Unit to which the message belongs. From: the value is ignored. String O M D.5.2.3.10 Additional Information Introduction The elements described in this section are not included in the DataPDU schema described in "DataPDU": • AckNack • SwGbl:Status • Sw:SnFPDMHistory • Sw:NotifSnFRequestHandle • SwInt:ValidationDescriptor These are Alliance Access or SWIFTNet-specific data elements that Alliance Access provides to the application for completeness. Further processing of these elements is not required, but their structure is listed. Note that the structure of these elements can evolve with future releases of SWIFTNet. ACK/NAK Element Description Type From To PseudoAckNack Alliance Access-generated Pseudo SWIFT Acknowledgement. String -- M SwGbl:Status Optional SWIFTNet report status. SwGbl:Status -- O 15 July 2011 507 Alliance Access 7.0.20 Generation of a Pseudo SWIFT Acknowledgement (ACKNAK) The Pseudo SWIFT Acknowledgement has the following structure: <AckNack> <PseudoAckNack> {1:F21BIC8(Sender_X1)ABranch(Sender_X1) SessionNbrSequenceNbr}{4:{177:LocalTime(YYMMDDHHMM)} {451:0(Ack)/1(Nack)}{405:Code}{311:ACK/NAK\r\nText} {108:Message_User_Reference(1..16)}} </PseudoAckNack> <SwGbl:Status> ... </SwGbl:Status> </AckNack> Note White spaces have been added for readability. Parts that are in bold are placeholders that are substituted with their actual value as follows: • BIC8(Sender_X1): the BIC8 of the sender X1, for instance SAAABEBB • Branch(Sender_X1): the branch of the sender X1, for instance XXX • SessionNbr: the emission session number, for instance 000012 • SequenceNbr: the emission sequence number, for instance 000000001 • LocalTime: the local time in YYMMDDHHMM format, for instance 0611061025 • 0(Ack)/1(Nack): 0 in case of ACK or 1 in case of NACK • ACK/NAK: either ACK or NACK • Message_User_Reference: the message user reference The Code and Text parts are optional. They are present on unsuccessful emission of a message on the network. The Code and Text values are filled as follows: 508 Code Text Description T02 Value of the first occurrence of <SwGbl.Details><SwGbl:Code> if present Transmission error When the value of the element <SwGbl:Severity> is either Fatal or Transient, and the value of the element <SwGbl:Code> is Sw.Gbl.NetworkTransmissionError. T04 File marked as duplicate by correspondent In the context of FileAct, the file sent is marked as duplicate by the correspondent. T05 File rejected by correspondent In the context of FileAct, the file sent is rejected by the correspondent. T06 File aborted by correspondent (remote abort) or File aborted by <user> (local abort) In the context of FileAct, the file transfer has been aborted either remotely by the correspondent during reception, or locally by the user sending the file. T03 Value of the first occurrence of <SwGbl.Details><SwGbl:Code> All other cases. LEN - In the context of FIN, the total FIN message length exceeds 10k. System Management Guide Appendix D - Message Formats Used in AI Code Text Description COR - In the context of FIN, the correspondent specified in the FIN messages is marked as inactive in the Correspondent File. AUT - In the context of FIN, there is no valid RMA authorisation to send the FIN message. ADR - In the context of FIN, there is an inconsistency between the message and the sender/receiver: A live message has a T&T destination as sender. A live message has a T&T destination as receiver. The message is not live and the sender is a LIVE destination (except for messages MT 076, 087, and 092). OTH - In the context of FIN, any other reason. Example: <AckNack><PseudoAckNack>{1:F21SAAABEBBAXXX000012000000001}{4:{177:0611061025} {451:1}{405:T02}{311:NAK Sw.SPX.TpCallTPENOENT}{108:REF-1-0610311645}}</PseudoAckNack> <SwGbl:Status>...</SwGbl:Status></AckNack> SwGbl:Status Element Description Type SwGbl:StatusAttributes Report status of top-level processing of SwGbl:StatusAttributes called function. Can occur multiple times [1..N] when the function does iterative processing (for example, a message validation function may return all syntax errors). From To -- M SwGbl:StatusAttributes Element Description Type From To SwGbl:Severity Possible values: String -- M • Fatal • Transient • Logic • Success • Warning SwGbl:Code Status code. The list of error codes is available in SWIFTNet Link Error Codes (part of the SWIFTNet Link documentation set). String -- M SwGbl:Parameter Content depends on the error. Any [0..N] -- O SwGbl:Text Textual description. No processing, except display/print for information, must be performed on this element. String -- O SwGbl:Action Proposed corrective action. String -- O 15 July 2011 509 Alliance Access 7.0.20 Element Description Type From To SwGbl:Details Lower level detailed report. SwGbl:Details [0..N] -- O Element Description Type From To SwGbl:Code Status code. String -- M SwGbl:Text Textual description. String -- O SwGbl:Action Proposed corrective action. String -- O Element Description Type From To Sw:SnFPDMHistory In case of previous delivery attempts, gives the delivery attempt history. Sw:SnFDeliveryHistory -- M From To -- O SwGbl:Details Sw:SnFPDMHistory Sw:SnFDeliveryHistory Element Description Type Sw:SnFDeliveryInfo Message delivery information. In case of disaster take-over (SWIFT side), all messages present in the queue at the moment of the disaster are flagged for possible duplicate delivery, but without delivery information. Sw:SnFDeliveryInfo [0..N] Sw:SnFDeliveryInfo Element Description Type From To Sw:SwiftTime SWIFT time of the delivery attempt (UTC). Format: YYYY-MM-DDTHH:MM:SSZ String -- O SwSec:UserDN Authoriser DN of the session owner. String -- O Sw:SnFSessionId Store-and-forward session identifier when the message was delivered. String -- O Format: <queue>:(d|p):<6 digit session number> SwInt:SNLId SNL ID of the physical SWIFTNet Link where message was delivered. String -- O Sw:RetryReason Reason why the message failed delivery. SwGbl:Status [0..1] -- O Sample SnFPDMHistory structure for SWIFTNet release 6.0, as described in the previous tables: <Sw:SnFPDMHistory> <Sw:SnFDeliveryInfo> <Sw:SwiftTime>2005-07-19T08:58:37Z</Sw:SwiftTime> <SwSec:UserDN>ou=zurich,o=bankwxyz,o=swift</SwSec:UserDN> <Sw:SnFSessionId>bankwxyz_applicq1:p:000458</Sw:SnFSessionId> <SwInt:SNLId>SNL00835D1</SwInt:SNLId> <Sw:RetryReason> <SwGbl:Status> 510 System Management Guide Appendix D - Message Formats Used in AI <SwGbl:StatusAttributes> <SwGbl:Severity>Transient</SwGbl:Severity> <SwGbl:Code>See Error Guide</SwGbl:Code> <SwGbl:Text>One liner error description</SwGbl:Text> <SwGbl:Action>Retry Message</SwGbl:Action> </SwGbl:StatusAttributes> </SwGbl:Status> </Sw:RetryReason> </Sw:SnFDeliveryInfo> </Sw:SnFPDMHistory> Sw:NotifSnFRequestHandle Element Description Type From To Sw:SnFRef Store-and-forward message reference of the notification. Contains the SwiftRef of the original message (see "SWIFTNetRequestAttribute"). String -- M Sw:SnFRefType Type of message for which this notification is provided. String -- M String -- M Sw:AckSwiftTime The SWIFT acceptance time of the request String ("Accepted", "Rejected") or generation time of the delivery notification request ("Failed") in UTC. Format: YYYY-MM-DDTHH:MM:SSZ -- M Sw:AckDescription Provides information about the acknowledgement. Free text. -- O Possible value: • InterAct Sw:AcceptStatus Type of store-and-forward notification. Possible values: • Accepted message accepted by the receiver • Rejected message rejected by the receiver • Failed SWIFT failed to deliver the message String In case the Sw:AcceptStatus is "Failed" (delivery notification generated by SWIFT), the Sw:AckDescription contains the following: • Message has expired (code SwGbl.MessageExpired) • Message delivery attempts exceeded system threshold (code SwGbl.MaxRetryExceeded) 15 July 2011 511 Alliance Access 7.0.20 Element Description Type From To Sw:AckInfo Provides information about the acknowledgement. Structured data that the client can analyse. String -- O In case the Sw:AcceptStatus is "Failed" (delivery notification generated by SWIFT), the Sw:AckInfo contains the following: SwRejectCode=<reject code> Where reject code is: SwGbl.MessageExpired SwGbl.MaxRetryExceeded SwInt:ValidationDescriptor Element Description Type From To SwInt:ValResult Indicates the result of validation. String -- M SwGbl:Status -- O Possible values: • Success • Warning • Fatal (not currently used) SwInt:ValStatus This contains the details of error(s) found. More than one SwGbl:StatusAttributes can be present. Present if SwInt:ValResult is Warning. Example: <SwInt:ValResult>Warning</SwInt:ValResult> <SwInt:ValStatus> <SwGbl:StatusAttributes> <SwGbl:Severity>Warning</SwGbl:Severity> <SwGbl:Code></SwGbl:Code> <SwGbl:Text></SwGbl:Text> </SwGbl:StatusAttributes> </SwInt:ValStatus> D.5.2.4 Message Reconciliation Scenario Overview This section describes how a message sent by an application can be reconciled with its network ACK and with the (optional) Delivery Notification subsequently sent by Alliance Access to the application. Process 512 1. When sending the message to Alliance Access, the application assigns a unique reference to the message which it puts in the element SenderReference of the Message DataPDU that contains the message. 2. After receiving and processing the Message DataPDU, Alliance Access sends the message over the network. When Alliance Access receives the network ACK (or NAK), it sends a TransmissionReport DataPDU to the application. System Management Guide Appendix D - Message Formats Used in AI This TransmissionReport DataPDU contains: • an element SenderReference containing the unique reference that was provided by the application in the original Message DataPDU • an element ReconciliationInfo containing the Message Input Reference (for an MT message) or the SWIFTRef (for an MX message); the contents of this element are used by the application for future reconciliation with the Delivery Notification (step 4). 3. When receiving a TransmissionReport DataPDU, the application can reconcile it with the original Message DataPDU through the contents of its element SenderReference. At this stage, the contents of the elements ReconciliationInfo, and SenderReference contained in the Transmission Report DataPDU must be stored together for future reconciliation of the Delivery Notification. Note that Alliance Access can possibly send the message multiple times; the application must be able to handle multiple TransmissionReports for the same message. 4. When Alliance Access receives a Delivery Notification for a message that has been sent and ACK'ed, two scenarios are possible: • If the Traffic Reconciliation component of Alliance Access is used to reconcile the Delivery Notification with the original message, then Alliance Access sends a DeliveryReport DataPDU to the application. The DeliveryReport contains an element SenderReference with the unique reference as the original message. In this scenario, the application can reconcile the DeliveryReport DataPDU with the original Message DataPDU through the contents of its element SenderReference. • If the Traffic Reconciliation component of Alliance Access is not used or cannot perform the reconciliation because the original message is no longer present in the Alliance Access database (due to archiving), then Alliance Access sends a DeliveryNotification DataPDU to the application. In this scenario, the application: – can reconcile the DeliveryNotification carried in the Message DataPDU the corresponding TransmissionReport DataPDU by matching the contents of its element ReconciliationInfo with the ReconciliationInfo it has stored when it received the TransmissionReport DataPDU from Alliance Access (step 3), – can then find back the original Message DataPDU from theTransmissionReport PDU through the SenderReference stored with the ReconciliationInfo (step 3). Note For MT messages, the DeliveryNotification DataPDU can be received by the application before the TransmissionReport DataPDU. A FIN Delivery Notification is a system message: system messages are processed by Alliance Access with a higher priority. The design of the application must take this into account. D.5.2.5 Examples D.5.2.5.1 Exchange of MT Messages D.5.2.5.1.1 Emission Flow DataPDUs Introduction The following sections contain examples of DataPDUs exchanged between an application and Alliance Access during the emission flow of an MT message. 15 July 2011 513 Alliance Access 7.0.20 Message Sent by an Application to Alliance Access The following shows an example of Message DataPDU sent by an application to Alliance Access: <?xml version="1.0" encoding="utf-8" ?> <DataPDU xmlns="urn:swift:saa:xsd:saa.2.0"> <Header> <Message> <SenderReference>REF10610311637</SenderReference> <MessageIdentifier>fin.199</MessageIdentifier> <Format>MT</Format> <Sender> <BIC12>SAARBEBBAXXX</BIC12> <FullName> <X1>SAARBEBBXXX</X1> </FullName> </Sender> <Receiver> <BIC12>SAARBEBBXXXX</BIC12> <FullName> <X1>SAARBEBBXXX</X1> </FullName> </Receiver> <InterfaceInfo> <UserReference>REF10610311637</UserReference> </InterfaceInfo> <NetworkInfo> <IsNotificationRequested>true</IsNotificationRequested> <FINNetworkInfo /> </NetworkInfo> <SecurityInfo> <FINSecurityInfo /> </SecurityInfo> </Message> </Header> <Body>DQo6MjA6VFJOIE1TRzEwMDANCjo3OTpNRVNTQUdFIFRFWFQ=</Body> </DataPDU> MessageStatus Sent by Alliance Access to the Application The following shows the MessageStatus DataPDU sent by Alliance Access to the application and the important information in this DataPDU is identified in bold: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:MessageStatus> <Saa:SenderReference>REF10610311637</Saa:SenderReference> <Saa:SeqNr>000001</Saa:SeqNr> <Saa:IsSuccess>true</Saa:IsSuccess> </Saa:MessageStatus> </Saa:Header> </Saa:DataPDU> TransmissionReport Sent by Alliance Access to the Application The following table shows the TransmissionReport DataPDU sent by Alliance Access to the application upon reception of the ACK. 514 System Management Guide Appendix D - Message Formats Used in AI The important information in this DataPDU is identified in bold: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:TransmissionReport> <Saa:SenderReference>REF10610311637</Saa:SenderReference> <Saa:ReconciliationInfo>061102SAARBEBBAXXX0023000049 </Saa:ReconciliationInfo> <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus> <Saa:OriginalInstanceAddressee> <Saa:X1>SAARBEBBXXX</Saa:X1> </Saa:OriginalInstanceAddressee> <Saa:ReportingApplication>FINInterface</Saa:ReportingApplication> <Saa:NetworkInfo> <Saa:Priority>Normal</Saa:Priority> <Saa:IsPossibleDuplicate>true</Saa:IsPossibleDuplicate> <Saa:IsNotificationRequested>true</Saa:IsNotificationRequested> <Saa:Service>swift.fin</Saa:Service> <Saa:Network>FIN</Saa:Network> <Saa:SessionNr>0023</Saa:SessionNr> <Saa:SeqNr>000049</Saa:SeqNr> <Saa:FINNetworkInfo> <Saa:MessageSyntaxVersion>0605</Saa:MessageSyntaxVersion> </Saa:FINNetworkInfo> </Saa:NetworkInfo> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>20061102093841</Saa:CreationTime> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Contents>{1:F21SAARBEBBAXXX0023000049}{4:{177:0611020938}{451:0} {108:REF10610311637}}</Saa:Contents> </Saa:Intervention> </Saa:Interventions> <Saa:IsRelatedInstanceOriginal>true</Saa:IsRelatedInstanceOriginal> <Saa:MessageCreator>ApplicationInterface</Saa:MessageCreator> <Saa:IsMessageModified>false</Saa:IsMessageModified> <Saa:MessageFields>HeaderAndBody</Saa:MessageFields> <Saa:Message> <Saa:SenderReference>REF10610311637</Saa:SenderReference> <Saa:MessageIdentifier>fin.199</Saa:MessageIdentifier> <Saa:Format>MT</Saa:Format> <Saa:SubFormat>Input</Saa:SubFormat> <Saa:Sender> <Saa:BIC12>SAARBEBBAXXX</Saa:BIC12> <Saa:FullName> <Saa:X1>SAARBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Sender> <Saa:Receiver> <Saa:BIC12>SAARBEBBXXXX</Saa:BIC12> <Saa:FullName> <Saa:X1>SAARBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:InterfaceInfo> <Saa:UserReference>REF10610311637</Saa:UserReference> <Saa:MessageCreator>ApplicationInterface</Saa:MessageCreator> <Saa:MessageContext>Report</Saa:MessageContext> <Saa:MessageNature>Financial</Saa:MessageNature> </Saa:InterfaceInfo> <Saa:NetworkInfo> <Saa:Priority>Normal</Saa:Priority> <Saa:IsPossibleDuplicate>true</Saa:IsPossibleDuplicate> <Saa:IsNotificationRequested>true 15 July 2011 515 Alliance Access 7.0.20 </Saa:IsNotificationRequested> <Saa:Service>swift.fin</Saa:Service> <Saa:Network>FIN</Saa:Network> <Saa:SessionNr>0023</Saa:SessionNr> <Saa:SeqNr>000049</Saa:SeqNr> <Saa:FINNetworkInfo> <Saa:MessageSyntaxVersion>0605</Saa:MessageSyntaxVersion> </Saa:FINNetworkInfo> </Saa:NetworkInfo> <Saa:SecurityInfo> <Saa:RMAResult>Success</Saa:RMAResult> <Saa:FINSecurityInfo> <Saa:ChecksumResult>Success</Saa:ChecksumResult> <Saa:ChecksumValue>6E2B36369332</Saa:ChecksumValue> <Saa:MACSignatureValue> <SwSec:Signature> <SwSec:SignedInfo> <Sw:Reference> <Sw:DigestValue>beDU9fHr0DzMj20uMsHHT+sDfdphSFbE0KwqCNMlIUo=</ Sw:DigestValue> </Sw:Reference> </SwSec:SignedInfo> <SwSec:SignatureValue>PEMF@Proc-Type: 4,MIC-ONLY Content-Domain: RFC822 EntrustFile-Version: 2.0 Originator-DN: cn=rma1,o=saarbebb,o=swift Orig-SN: 1147824225 MIC-Info: SHA256, RSA, CpjLYQA6OuWErTFK6aBCleoOdHqJxFeM1GeJE2dyQET+79NvyjeWf6V8CfaEXn89 GSMyou5lSyzTNc3kIPBPPKaEyyFQsYZuXm64dVvzwdoWc/xev86CkSZyIyiGML0q ELoeVna3i61v3cSNIXRPErgVuOJ52XO90d1UQ9G5czI1rboPqC8a3dy4RXeinxJm QjWRwdNZ82YD7IqFDpG9cduOzbs/Ppmkla0cR+9RQDTRlfTD3LMo7VKwthqxbXfi 2m0p1ffs6/qKpUvuFQGrt5gsRIl8v03t6RPBFJ01CefzplQ6e5mU8T6FUPy5zNWL ufG/XZx1D+gDD8085ZqYqw== </SwSec:SignatureValue> <SwSec:KeyInfo> <SwSec:SignDN>cn=rma1,o=saarbebb,o=swift </SwSec:SignDN> <SwSec:CertPolicyId>1.3.21.6.2 </SwSec:CertPolicyId> </SwSec:KeyInfo> <SwSec:Manifest> <Sw:Reference> <Sw:DigestRef>M</Sw:DigestRef> <Sw:DigestValue>K3GPdVCheunY0XW46FAILtOHM44A3wLrrFxsCbCEgOA=</ Sw:DigestValue> </Sw:Reference> <Sw:Reference> <Sw:DigestRef>Sw.E2S</Sw:DigestRef> <Sw:DigestValue>fGllfE9CYvXZWm5n0TywkTvd4RKLveQ9/F0w8H+VPMs=</ Sw:DigestValue> </Sw:Reference> </SwSec:Manifest> </SwSec:Signature> </Saa:MACSignatureValue> </Saa:FINSecurityInfo> </Saa:SecurityInfo> </Saa:Message> </Saa:TransmissionReport> </Saa:Header> <Saa:Body>DQo6MjA6VFJOIE1TRzEwMDANCjo3OTpNRVNTQUdFIFRFWFQ=</Saa:Body> </Saa:DataPDU> DeliveryNotification Sent by Alliance Access to the Application The following example shows the DeliveryNotification DataPDU sent by Alliance Access to the application upon reception of a Delivery Notification corresponding to the original message. It 516 System Management Guide Appendix D - Message Formats Used in AI can be reconciled with the TransmissionReport DataPDU through the ReconciliationInfo element, then with the Message DataPDU through the SenderReference element of the TransmissionReport DataPDU. The important information in this DataPDU is identified in bold: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:DeliveryNotification> <Saa:ReconciliationInfo>061102SAARBEBBAXXX0023000049 </Saa:ReconciliationInfo> <Saa:ReceiverDeliveryStatus>RcvDelivered </Saa:ReceiverDeliveryStatus> <Saa:MessageIdentifier>fin.011</Saa:MessageIdentifier> <Saa:Receiver> <Saa:BIC12>SAARBEBBAXXX</Saa:BIC12> <Saa:FullName> <Saa:X1>SAARBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:InterfaceInfo> <Saa:MessageCreator>FINInterface</Saa:MessageCreator> <Saa:MessageContext>Original</Saa:MessageContext> <Saa:MessageNature>Network</Saa:MessageNature> </Saa:InterfaceInfo> <Saa:NetworkInfo> <Saa:Priority>System</Saa:Priority> <Saa:IsPossibleDuplicate>false</Saa:IsPossibleDuplicate> <Saa:Service>swift.fin</Saa:Service> <Saa:Network>FIN</Saa:Network> <Saa:SessionNr>0023</Saa:SessionNr> <Saa:SeqNr>000299</Saa:SeqNr> <Saa:FINNetworkInfo> <Saa:MessageSyntaxVersion>0605</Saa:MessageSyntaxVersion> <Saa:CorrespondentInputReference>061102DYLQXXXXHXXX0000413146 </Saa:CorrespondentInputReference> <Saa:CorrespondentInputTime>20061102083900 </Saa:CorrespondentInputTime> <Saa:LocalOutputTime>20061102093900</Saa:LocalOutputTime> <Saa:SystemOriginated>{SYS:}</Saa:SystemOriginated> </Saa:FINNetworkInfo> </Saa:NetworkInfo> <Saa:SecurityInfo> <Saa:FINSecurityInfo> <Saa:ChecksumResult>Success</Saa:ChecksumResult> <Saa:ChecksumValue>8BB8247F0C2E</Saa:ChecksumValue> </Saa:FINSecurityInfo> </Saa:SecurityInfo> </Saa:DeliveryNotification> </Saa:Header> <Saa:Body>ezE3NTowOTM4fXsxMDY6MDYxMTAyU0FBUkJFQkJBWFhYMDAyMzAwMDA0OX17MTA4OlJF RjEwNjEwMzExNjM3fXsxNzU6MDkzOH17MTA3OjA2MTEwMlNBQVJCRUJCQVhYWDAwMjMwMDAyOTh9</ Saa:Body> </Saa:DataPDU> DeliveryReport Sent by Alliance Access to the Application The following example shows the DeliveryReport DataPDU sent by Alliance Access to the application upon reception of a message that is the Delivery Notification corresponding to the initial message when the Traffic Reconciliation component of Alliance Access is used. It can be 15 July 2011 517 Alliance Access 7.0.20 reconciled with the TransmissionReport DataPDU and the Message DataPDU through the SenderReference element. The important information in this DataPDU is identified in bold: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:DeliveryReport> <Saa:SenderReference>REF10610311637</Saa:SenderReference> <Saa:ReceiverDeliveryStatus>RcvDelivered </Saa:ReceiverDeliveryStatus> <Saa:OriginalInstanceAddressee> <Saa:X1>SAARBEBBXXX</Saa:X1> </Saa:OriginalInstanceAddressee> <Saa:ReportingApplication>TrafficReconciliation </Saa:ReportingApplication> <Saa:NetworkInfo> <Saa:Priority>Normal</Saa:Priority> <Saa:IsPossibleDuplicate>true</Saa:IsPossibleDuplicate> <Saa:IsNotificationRequested>true</Saa:IsNotificationRequested> <Saa:Service>swift.fin</Saa:Service> <Saa:Network>FIN</Saa:Network> <Saa:SessionNr>0023</Saa:SessionNr> <Saa:SeqNr>000049</Saa:SeqNr> <Saa:FINNetworkInfo> <Saa:MessageSyntaxVersion>0605</Saa:MessageSyntaxVersion> </Saa:FINNetworkInfo> </Saa:NetworkInfo> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>DeliveryReport</Saa:IntvCategory> <Saa:CreationTime>20061102094143</Saa:CreationTime> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Contents>{175:0938}{106:061102SAARBEBBAXXX0023000049} {108:REF10610311637}{175:0938}{107:061102SAARBEBBAXXX0023000298} </Saa:Contents> </Saa:Intervention> </Saa:Interventions> <Saa:IsRelatedInstanceOriginal>true</Saa:IsRelatedInstanceOriginal> <Saa:MessageCreator>ApplicationInterface</Saa:MessageCreator> <Saa:IsMessageModified>false</Saa:IsMessageModified> <Saa:MessageFields>NoOriginal</Saa:MessageFields> </Saa:DeliveryReport> </Saa:Header> </Saa:DataPDU> D.5.2.5.1.2 Reception Flow DataPDUs Message Sent by Alliance Access to the Application The following shows an example of Message DataPDU sent by an application to Alliance Access upon reception of a message from the network: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:Message> <Saa:SenderReference>OSAARBEBBXXX199TRN MSG1000 </Saa:SenderReference> <Saa:MessageIdentifier>fin.199</Saa:MessageIdentifier> <Saa:Format>MT</Saa:Format> <Saa:SubFormat>Output</Saa:SubFormat> <Saa:Sender> <Saa:BIC12>SAARBEBBAXXX</Saa:BIC12> 518 System Management Guide Appendix D - Message Formats Used in AI <Saa:FullName> <Saa:X1>SAARBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Sender> <Saa:Receiver> <Saa:BIC12>SAARBEBBAXXX</Saa:BIC12> <Saa:FullName> <Saa:X1>SAARBEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:InterfaceInfo> <Saa:UserReference>REF10610311637</Saa:UserReference> <Saa:MessageCreator>FINInterface</Saa:MessageCreator> <Saa:MessageContext>Original</Saa:MessageContext> <Saa:MessageNature>Financial</Saa:MessageNature> </Saa:InterfaceInfo> <Saa:NetworkInfo> <Saa:Priority>Normal</Saa:Priority> <Saa:IsPossibleDuplicate>true</Saa:IsPossibleDuplicate> <Saa:DuplicateHistory> <Saa:PDE>{PDE:}</Saa:PDE> </Saa:DuplicateHistory> <Saa:Service>swift.fin</Saa:Service> <Saa:Network>FIN</Saa:Network> <Saa:SessionNr>0023</Saa:SessionNr> <Saa:SeqNr>000298</Saa:SeqNr> <Saa:FINNetworkInfo> <Saa:MessageSyntaxVersion>0605</Saa:MessageSyntaxVersion> <Saa:CorrespondentInputReference>061102SAARBEBBAXXX0023000049 </Saa:CorrespondentInputReference> <Saa:CorrespondentInputTime>20061102093800 </Saa:CorrespondentInputTime> <Saa:LocalOutputTime>20061102093800</Saa:LocalOutputTime> </Saa:FINNetworkInfo> </Saa:NetworkInfo> <Saa:SecurityInfo> <Saa:RMAResult>Success</Saa:RMAResult> <Saa:FINSecurityInfo> <Saa:ChecksumResult>Success</Saa:ChecksumResult> <Saa:ChecksumValue>6E2B36369332</Saa:ChecksumValue> <Saa:MACSignatureValue> <SwSec:Signature> <SwSec:SignedInfo> <Sw:Reference> <Sw:DigestValue>beDU9fHr0DzMj20uMsHHT+sDfdphSFbE0KwqCNMlIUo=</ Sw:DigestValue> </Sw:Reference> </SwSec:SignedInfo> <SwSec:SignatureValue>PEMF@Proc-Type: 4,MIC-ONLY Content-Domain: RFC822 EntrustFile-Version: 2.0 Originator-DN: cn=rma1,o=saarbebb,o=swift Orig-SN: 1147824225 MIC-Info: SHA256, RSA, CpjLYQA6OuWErTFK6aBCleoOdHqJxFeM1GeJE2dyQET+79NvyjeWf6V8CfaEXn89 GSMyou5lSyzTNc3kIPBPPKaEyyFQsYZuXm64dVvzwdoWc/xev86CkSZyIyiGML0q ELoeVna3i61v3cSNIXRPErgVuOJ52XO90d1UQ9G5czI1rboPqC8a3dy4RXeinxJm QjWRwdNZ82YD7IqFDpG9cduOzbs/Ppmkla0cR+9RQDTRlfTD3LMo7VKwthqxbXfi 2m0p1ffs6/qKpUvuFQGrt5gsRIl8v03t6RPBFJ01CefzplQ6e5mU8T6FUPy5zNWL ufG/XZx1D+gDD8085ZqYqw== </SwSec:SignatureValue> <SwSec:KeyInfo> <SwSec:SignDN>cn=rma1,o=saarbebb,o=swift </SwSec:SignDN> <SwSec:CertPolicyId>1.3.21.6.2</SwSec:CertPolicyId> </SwSec:KeyInfo> <SwSec:Manifest> 15 July 2011 519 Alliance Access 7.0.20 <Sw:Reference> <Sw:DigestRef>M</Sw:DigestRef> <Sw:DigestValue>K3GPdVCheunY0XW46FAILtOHM44A3wLrrFxsCbCEgOA=</ Sw:DigestValue> </Sw:Reference> <Sw:Reference> <Sw:DigestRef>Sw.E2S</Sw:DigestRef> <Sw:DigestValue>fGllfE9CYvXZWm5n0TywkTvd4RKLveQ9/F0w8H+VPMs=</ Sw:DigestValue> </Sw:Reference> </SwSec:Manifest> </SwSec:Signature> </Saa:MACSignatureValue> </Saa:FINSecurityInfo> </Saa:SecurityInfo> </Saa:Message> </Saa:Header> <Saa:Body>DQo6MjA6VFJOIE1TRzEwMDANCjo3OTpNRVNTQUdFIFRFWFQ=</Saa:Body> </Saa:DataPDU> D.5.2.5.2 Exchange of MX Messages D.5.2.5.2.1 Emission Flow DataPDUs Overview The following sections contain examples of DataPDUs exchanged between an application and Alliance Access during the emission flow of an MX message. Message Sent by an Application to Alliance Access The following shows an example of Message DataPDU sent by an application to Alliance Access: <?xml version="1.0" encoding="utf-8" ?> <DataPDU xmlns="urn:swift:saa:xsd:saa.2.0"> <Header> <Message> <SenderReference>REF10610311505</SenderReference> <MessageIdentifier>camt.029.001.02</MessageIdentifier> <Format>MX</Format> <Sender> <DN>o=saaabebb,o=swift</DN> <FullName> <X1>SAAABEBBXXX</X1> </FullName> </Sender> <Receiver> <DN>o=saaabebb,o=swift</DN> <FullName> <X1>SAAABEBBXXX</X1> </FullName> </Receiver> <InterfaceInfo> <UserReference>REF10610311505</UserReference> </InterfaceInfo> <NetworkInfo> <Service>swift.eni</Service> </NetworkInfo> <SecurityInfo> <SWIFTNetSecurityInfo /> </SecurityInfo> </Message> </Header> <Body> <AppHdr xmlns="urn:swift:xsd:$ahV10"> 520 System Management Guide Appendix D - Message Formats Used in AI <MsgRef>REF10610311505</MsgRef> <CrDate>2006-10-31T03:05:41.502</CrDate> </AppHdr> <Document xmlns="urn:swift:xsd:swift.eni$camt.029.001.02"> <camt.029.001.02> <Assgnmt> <Id>RCUSTA20050001</Id> <Assgnr>AAAAGB2L</Assgnr> <Assgne>CUSAGB2L</Assgne> <CreDtTm>2005-01-27T11:04:27</CreDtTm> </Assgnmt> <RslvdCase> <Id>CCCC-MOD-20050127-0003</Id> <Cretr>CUSAGB2L</Cretr> </RslvdCase> <Sts> <Conf>MODI</Conf> </Sts> </camt.029.001.02> </Document> </Body> </DataPDU> MessageStatus Sent by Alliance Access to the Application The following example shows the MessageStatus DataPDU sent by Alliance Access to the application and the important information in this DataPDU is identified in bold: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:MessageStatus> <Saa:SenderReference>REF10610311505</Saa:SenderReference> <Saa:SeqNr>000001</Saa:SeqNr> <Saa:IsSuccess>true</Saa:IsSuccess> </Saa:MessageStatus> </Saa:Header> </Saa:DataPDU> TransmissionReport Sent by Alliance Access to the Application The following example shows the TransmissionReport DataPDU sent by Alliance Access to the application upon reception of the ACK. The important information in this DataPDU is identified in bold: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:TransmissionReport> <Saa:SenderReference>REF10610311505</Saa:SenderReference> <Saa:ReconciliationInfo>SWITCH21-2006-11-02T08:41:47.11481.1454972Z </Saa:ReconciliationInfo> <Saa:NetworkDeliveryStatus>NetworkAcked</Saa:NetworkDeliveryStatus> <Saa:OriginalInstanceAddressee> <Saa:X1>SAAABEBBXXX</Saa:X1> </Saa:OriginalInstanceAddressee> <Saa:ReportingApplication>SWIFTNetInterface </Saa:ReportingApplication> <Saa:NetworkInfo> <Saa:Priority>Normal</Saa:Priority> <Saa:IsPossibleDuplicate>true</Saa:IsPossibleDuplicate> <Saa:Service>swift.eni</Saa:Service> <Saa:Network>SWIFTNet</Saa:Network> 15 July 2011 521 Alliance Access 7.0.20 <Saa:SessionNr>000008</Saa:SessionNr> <Saa:SeqNr>000000001</Saa:SeqNr> <Saa:SWIFTNetNetworkInfo> <Saa:SWIFTRef>SWITCH21-2006-11-02T08:41:47.11481.1454972Z </Saa:SWIFTRef> <Saa:SNLRef>SNL10391-2006-11-02T08:35:20.6268.030308Z </Saa:SNLRef> <Saa:Reference>c98e3458-1dd1-11b2-91dd-5bdc6d3f0133 </Saa:Reference> <Saa:SnFInputTime>0102:2006-11-02T08:26:47</Saa:SnFInputTime> </Saa:SWIFTNetNetworkInfo> </Saa:NetworkInfo> <Saa:Interventions> <Saa:Intervention> <Saa:IntvCategory>TransmissionReport</Saa:IntvCategory> <Saa:CreationTime>20061102093520</Saa:CreationTime> <Saa:OperatorOrigin>SYSTEM</Saa:OperatorOrigin> <Saa:Contents> <AckNack> <PseudoAckNack>{1:F21SAAABEBBAXXX000008000000001}{4:{177:0611020935} {451:0}{311:ACK}{108:REF10610311505}}</PseudoAckNack> </AckNack> </Saa:Contents> </Saa:Intervention> </Saa:Interventions> <Saa:IsRelatedInstanceOriginal>true</Saa:IsRelatedInstanceOriginal> <Saa:MessageCreator>ApplicationInterface</Saa:MessageCreator> <Saa:IsMessageModified>false</Saa:IsMessageModified> <Saa:MessageFields>NoOriginal</Saa:MessageFields> </Saa:TransmissionReport> </Saa:Header> </Saa:DataPDU> DeliveryNotification Sent by Alliance Access to the Application The following example shows the Message DataPDU sent by Alliance Access to the application upon reception of a message that is the Delivery Notification corresponding to the initial MX message. It can be reconciled with the TransmissionReport DataPDU through the ReconciliationInfo element, then with the Message DataPDU through the SenderReference element of the TransmissionReport DataPDU. The important information in this DataPDU is identified in bold: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:DeliveryNotification> <Saa:ReconciliationInfo>SWITCH21-2006-11-02T08:41:47.11481.1454972Z </Saa:ReconciliationInfo> <Saa:ReceiverDeliveryStatus>RcvDelivered </Saa:ReceiverDeliveryStatus> <Saa:MessageIdentifier>Delivery Notification</Saa:MessageIdentifier> <Saa:InterfaceInfo> <Saa:MessageCreator>SWIFTNetInterface</Saa:MessageCreator> <Saa:MessageContext>Original</Saa:MessageContext> <Saa:MessageNature>Network</Saa:MessageNature> </Saa:InterfaceInfo> <Saa:NetworkInfo> <Saa:Priority>Normal</Saa:Priority> <Saa:IsPossibleDuplicate>false</Saa:IsPossibleDuplicate> <Saa:Network>SWIFTNet</Saa:Network> <Saa:SessionNr>188959</Saa:SessionNr> <Saa:SeqNr>000000155</Saa:SeqNr> </Saa:NetworkInfo> </Saa:DeliveryNotification> </Saa:Header> 522 System Management Guide Appendix D - Message Formats Used in AI <Saa:Body> <Sw:NotifySnFRequestHandle> <Sw:SnFRef>SWITCH21-2006-11-02T08:41:47.11481.1454972Z</Sw:SnFRef> <Sw:SnFRefType>InterAct</Sw:SnFRefType> <Sw:AcceptStatus>Accepted</Sw:AcceptStatus> <Sw:AckSwiftTime>2006-11-02T08:39:29Z</Sw:AckSwiftTime> <Sw:AckInfo>Acked</Sw:AckInfo> </Sw:NotifySnFRequestHandle> </Saa:Body> </Saa:DataPDU> D.5.2.5.2.2 Reception Flow DataPDUs Message Sent by Alliance Access to the Application The following example shows an example of Message DataPDU sent by an application to Alliance Access upon reception of a message from the network: <?xml version="1.0" encoding="UTF-8" ?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:Message> <Saa:SenderReference>OSAAABEBBXXX029REF10610311505 </Saa:SenderReference> <Saa:MessageIdentifier>camt.029.001.02</Saa:MessageIdentifier> <Saa:Format>MX</Saa:Format> <Saa:SubFormat>Output</Saa:SubFormat> <Saa:Sender> <Saa:DN>o=saaabebb,o=swift</Saa:DN> <Saa:FullName> <Saa:X1>SAAABEBBXXX</Saa:X1> </Saa:FullName> </Saa:Sender> <Saa:Receiver> <Saa:DN>o=saaabebb,o=swift</Saa:DN> <Saa:FullName> <Saa:X1>SAAABEBBXXX</Saa:X1> </Saa:FullName> </Saa:Receiver> <Saa:InterfaceInfo> <Saa:UserReference>REF10610311505</Saa:UserReference> <Saa:MessageCreator>SWIFTNetInterface</Saa:MessageCreator> <Saa:MessageContext>Original</Saa:MessageContext> <Saa:MessageNature>Financial</Saa:MessageNature> </Saa:InterfaceInfo> <Saa:NetworkInfo> <Saa:Priority>Normal</Saa:Priority> <Saa:IsPossibleDuplicate>true</Saa:IsPossibleDuplicate> <Saa:Service>swift.eni</Saa:Service> <Saa:Network>SWIFTNet</Saa:Network> <Saa:SessionNr>188959</Saa:SessionNr> <Saa:SeqNr>000000154</Saa:SeqNr> <Saa:SWIFTNetNetworkInfo> <Saa:SWIFTRef>SWITCH21-2006-11-02T08:41:47.11481.1454972Z </Saa:SWIFTRef> <Saa:SNLRef>SNL10391-2006-11-02T08:35:20.6268.030308Z </Saa:SNLRef> <Saa:Reference>14be9dc8-1dd2-11b2-91dd-5bdc6d3f0133 </Saa:Reference> <Saa:SnFQueueName>saaabebb_enimsg</Saa:SnFQueueName> <Saa:ValidationDescriptor> <SwInt:ValResult>Warning</SwInt:ValResult> <SwInt:ValStatus> <SwGbl:StatusAttributes> <SwGbl:Severity>Warning</SwGbl:Severity> 15 July 2011 523 Alliance Access 7.0.20 <SwGbl:Code>Sw.MVAL.ValidationWarning</SwGbl:Code> <SwGbl:Text>This message could not be validated due to an internal SWIFT error</SwGbl:Text> <SwGbl:Action>Contact customer support </SwGbl:Action> </SwGbl:StatusAttributes> </SwInt:ValStatus> </Saa:ValidationDescriptor> </Saa:SWIFTNetNetworkInfo> </Saa:NetworkInfo> <Saa:SecurityInfo> <Saa:SWIFTNetSecurityInfo> <Saa:SignerDN>cn=rma2,o=saaabebb,o=swift</Saa:SignerDN> <Saa:NRType>SvcMand</Saa:NRType> <Saa:NRWarning>WARNING</Saa:NRWarning> <Saa:SignatureResult>Success</Saa:SignatureResult> <Saa:SignatureValue> <SwSec:CryptoInternal> <SwSec:CipherKey>UEVNRkBQcm9jLVR5cGU6IDQsTUlDLU9OTFkNCkNvbnRlbnQtRG9tYWluOiBSR kM4MjINCkVudHJ1c3RGaWxlLVZlcnNpb246IDIuMA0KT3JpZ2luYXRvci1ETjogY249cm1hMixvPXN hYWFiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDc4MjUyNjcNCk1JQy1JbmZvOiBTSEExLCBSU0EsD QogV1Bwb1QyU1R0OFYydzZ3NnhaV3d2c2R5bk9jTUpaQUtodHJpZklMNDNlNS9rdThmSHc4bWppUlp seFNBYnRkUA0KIEl6Z2JrcDdKTDZ3WDI5WmVjWHVpTFpzZWJzbVFQRjBBR3RBU1hsaXZNK3NPK29BV EV0emRnMi9naE8rR1c0NDkNCiBONk1IYmU3RDlRN3dDa2FOQnRCTS9ucTJOVkhvM050dXY5dFBOcWN Iamg0b2NtamtlV0g2TjZWVzRkUWU4SW1aDQogVFZxRnhpME9ZTkRtcmQ1aW1INUQzUXkzdldIYVo4K zFDbHltMFNkckViS2YxWUcvOXA1Z05YaXBMN1MxcWxPbg0KIG0vMjBUSkdTd2hKSVdaajY4aW9GcjN 5WHBhZDRTWUpGSjVseEhFRFBUL1hRVjNkbFNYazl3eHNoRTVVYWd0aDcNCiBrME5EdmNzRER1RlYvM jZZcmY3d3NnPT0NCg==</SwSec:CipherKey> <SwSec:CryptoProtocol>4.0:3.0</SwSec:CryptoProtocol> </SwSec:CryptoInternal> <SwSec:CryptoDescriptor> <SwSec:MemberRef>RequestPayload</SwSec:MemberRef> <SwSec:MemberRef>RequestHeader</SwSec:MemberRef> <SwSec:MemberRef>RequestDescriptor.SwiftRequestRef </SwSec:MemberRef> <SwSec:SignDN>cn=rma2,o=saaabebb,o=swift</SwSec:SignDN> <SwSec:CertPolicyId>1.3.21.6.2</SwSec:CertPolicyId> </SwSec:CryptoDescriptor> </Saa:SignatureValue> </Saa:SWIFTNetSecurityInfo> </Saa:SecurityInfo> </Saa:Message> </Saa:Header> <Saa:Body> <AppHdr xmlns="urn:swift:xsd:$ahV10"> <MsgRef>REF10610311505</MsgRef> <CrDate>2006-10-31T03:05:41.502</CrDate> </AppHdr> <Document xmlns="urn:swift:xsd:swift.eni$camt.029.001.02"> <camt.029.001.02> <Assgnmt> <Id>RCUSTA20050001</Id> <Assgnr>AAAAGB2L</Assgnr> <Assgne>CUSAGB2L</Assgne> <CreDtTm>2005-01-27T11:04:27</CreDtTm> </Assgnmt> <RslvdCase> <Id>CCCC-MOD-20050127-0003</Id> <Cretr>CUSAGB2L</Cretr> </RslvdCase> <Sts> <Conf>MODI</Conf> </Sts> </camt.029.001.02> </Document> </Saa:Body> 524 System Management Guide Appendix D - Message Formats Used in AI </Saa:DataPDU> D.5.2.5.3 SessionStatus DataPDU Sent by Alliance Access to the Application Case of a successful session <?xml version="1.0" encoding="utf-8"?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:SessionStatus> <Saa:MessagePartner>CVEFileInput</Saa:MessagePartner> <Saa:CreationTime>20060223112705</Saa:CreationTime> <Saa:InputFile>D:\Batch\Input\success.mx</Saa:InputFile> <Saa:SessionNr>0041</Saa:SessionNr> <Saa:IsSuccess>true</Saa:IsSuccess> <Saa:Accepted>10</Saa:Accepted> <Saa:Rejected>0</Saa:Rejected> </Saa:SessionStatus> </Saa:Header> </Saa:DataPDU> Case of an aborted session <?xml version="1.0" encoding="utf-8"?> <Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0" xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwGbl="urn:swift:snl:ns.SwGbl" xmlns:SwSec="urn:swift:snl:ns.SwSec"> <Saa:Header> <Saa:SessionStatus> <Saa:MessagePartner>CVEForcedInput</Saa:MessagePartner> <Saa:CreationTime>20060224143554</Saa:CreationTime> <Saa:InputFile>D:\Batch\Input\formatconflict.rje</Saa:InputFile> <Saa:SessionNr>0001</Saa:SessionNr> <Saa:IsSuccess>false</Saa:IsSuccess> <Saa:ErrorCode>EFILEINVFORMAT</Saa:ErrorCode> <Saa:ErrorText> DataPDU format does not match value configured in SAA </Saa:ErrorText> </Saa:SessionStatus> </Saa:Header> </Saa:DataPDU> D.5.2.6 Computing the Signature of a DataPDU Algorithm The signature, also referred to as local message authentication code (LMAC), is computed using the algorithm HMAC based on SHA-256 as described in ISO/IEC 9797 (see RFC 2104 HMAC: Keyed-Hashing for Message Authentication - February 1997). This way of producing a message authentication code has the following features: • Fast to compute • One way (irreversible). Algorithm specification The HMAC algorithm produces a 128 bit LMAC. 15 July 2011 525 Alliance Access 7.0.20 To compute the LMAC, the algorithm needs: • A bit stream M representing the message content to sign (see "Content to sign" on page 526). • A truncation mask keeping only the first 128 bits (out of 256 bits). The LMAC must be converted in Base64 using standard Base-64 content transfer encoding as specified in RFC 1521. The encoded value is the Signature as specified in the Alliance Access exchange PDU (see "Protocol Data Units" on page 476). Content to sign The complete DataPDU field is taken as the bit stream for the authentication algorithm, including the string <?xml version="1.0" encoding="utf-8"?>. DataPDU encoding and format The bit stream of the DataPDU is to be preserved from the signature time until the verification time. The steps to compute a signature from a DataPDU are: 1. The original DataPDU, whatever it is, is considered as a bit stream. 2. This bit stream is used to compute the signature. 3. The signature accompanies the DataPDU. The steps to verify a signature of a DataPDU are: 1. The received DataPDU, whatever it is, is considered as a bit stream. 2. This bit stream is used to compute the signature. 3. This computed signature is compared with the one that accompanies the DataPDU. Warning about character sets It is recommended to avoid any character set translation between the signature time and the verification time. It is anyway the typical case and the simplest design. However, the convention above does not force to preserve the character set of a DataPDU all the time. If necessary, various translations can occur during the transport of a DataPDU as far as the original bit stream can be restored at verification time. Warning about XML representations is recommended to avoid any XML transformation between the signature time and the verification time. It is anyway the typical case and the simplest design. However, the convention above does not force to preserve the XML representation of a DataPDU. If necessary, various XML transformations can occur during the transport of a DataPDU as far as the original bit stream can be restored at verification time. For example, the business content of a DataPDU (10£ > 5£) can have this XML representation using the character set ISO-8859-1 and a CDATA section: <A><![CDATA[10£ > 5£]]> </A> This can be transformed to this XML representation using US-ASCII and escaped characters: <A>10Á > 5Á</A> The business content is not changed, but the bit stream of the DataPDU is totally different. 526 System Management Guide Appendix D - Message Formats Used in AI D.5.2.7 Error Codes Overview This section lists the possible error codes and associated error text that can be returned in the MessageStatus and the SessionStatus. D.5.2.7.1 MessageStatus MessageStatus error codes Error code Error text EFORMAT Message text format error EINVSENDERLT(1) FIN sender logical terminal does not exist EINVSENDER(1) The sender DN does not contain an Alliance Access licensed destination ESIGNATURE DataPDU Local Authentication error EPROFILE(2) Operator profile does not allow creating this message EINVDATAPDU DataPDU syntax error EDISPOSITION Message cannot be routed or disposed EBROADCAST(3) Nickname has no mapping in Alliance Access EFAILURE(4) An error occurred during the message processing (1) Not applicable to MQSA: mapped to EFAILURE. (2) Not applicable to MQSA: no mapping. (3) Currently not applicable to MQSA. (4) MQSA only. D.5.2.7.2 SessionStatus SessionStatus error codes 15 July 2011 Error code Error text ESESSABORTED Session aborted EFILEDUPDIGEST File with same digest already received EFILEDUPFILENAME File with same name already received EFILEINVALID File format error EFILEINVFORMAT DataPDU format does not match value configured in Alliance Access EFILEINVMESSAGE File contains a DataPDU with the wrong format EFILEINVFILENAME File name not valid EFILENOTADIRECTORY File path name not valid EFILEDOESNOTEXIST No such file or directory EFILENOACCESS File access denied EINTERNAL Internal error 527 Alliance Access 7.0.20 D.5.3 Migration Path from Version 1 to Version 2 Overview To ease the migration from XML v1 to XML v2, the following table lists the mapping between XML v1 and XML v2 data elements. The first column contains the original XML v1 structures and elements. The second column contains the mapping to be used when migrating to XML v2. A dot between two elements indicates that the second element is a sub-element. For instance, Message.SubFormat means the SubFormat element within the Message structure. Wherever the element name {PDUType} is mentioned, it must be replaced with: • Message, if the PDU carries a message • TransmissionReport, if the PDU carries a transmission report • DeliveryReport, if the PDU carries a delivery report. Version 1 Type/Element DataPDU Report 528 Version 2 Mapping SenderReference {PDUType}.SenderReference Message Message Report {PDUType} LogicalReply MessageStatus Addressee {PDUType}.OriginalInstanceAddressee OrigMessageFields {PDUType}.MessageFields See note 1. OrigMessage {PDUType}.Message ReportLPI {PDUType} TransmissionReport TransmissionReport DeliveryReport DeliveryReport System Management Guide Appendix D - Message Formats Used in AI Version 1 Type/Element Message Version 2 Mapping MessageFormat Message.Format MessageSubFormat Message.SubFormat Sender Message.Sender.FullName Receiver One of the following, depending on the receiver type (Nickname or FullName): • Message.Receiver.Nickname • Message.Receiver.FullName MessageSRI MessageTPI 15 July 2011 LiveMessage Not present. For MX, it can be derived from the service name (presence of !p). For MT, it can be derived from the BIC. MessageNature Message.InterfaceInfo.MessageNature In Version 2 this tag is optional: Alliance Access determines the nature automatically (always Financial for MX, derived from syntax for MT) if it is not present. This is different compared to Version 1. MessageLPI The subfields of this composite element are mapped to Message.InterfaceInfo, Message.SecurityInfo and Message.NetworkInfo. Check the details of MessageLPI below. MessageSRI The subfields of this composite element are mapped to both Message.InterfaceInfo and Message.NetworkInfo. Check the details of MessageSRI below. MessageTPI Message.NetworkInfo MessageText DataPDU.Body In Version 2 this tag has been moved from the Message to the DataPDU itself. UserReference Message.InterfaceInfo.UserReference UserPDE Message.NetworkInfo.IsPossibleDuplicate NetworkDelivNotify Message.NetworkInfo.IsNotificationRequested Network Message.NetworkInfo.Network See note 2. NetworkPriority Message.NetworkInfo.Priority NetworkSessionNr Message.NetworkInfo.SessionNr NetworkSeqNr Message.NetworkInfo.SeqNr DuplCreation This element has been split into 2 distinct elements: Message.NetworkInfo.IsPossibleDuplicate and Message.NetworkInfo.DuplicateHistory. 529 Alliance Access 7.0.20 Version 1 Type/Element MessageLPI ReportLPI DeliveryReport 530 Version 2 Mapping OriginalMessage Message.InterfaceInfo.MessageContext ModifyAllowed Message.InterfaceInfo.IsModificationAllowed DeleteInhibited Was not used. Not present in Version 2. MinValidation Message.InterfaceInfo.ValidationLevel CBTPriority Was not used. Not present in Version 2. DispositionState Message.InterfaceInfo.RoutingInstruction.RoutingStep See note 3. NetworkAttribute NetworkInfo SecurityAttribute Message.SecurityInfo FormatAttribute Was reserved for future use in Version 1. Not present in Version 2. TargetApplication Message.InterfaceInfo.RoutingInstruction MessageOrigin Message.InterfaceInfo.MessageCreator CBTRoutingInfo Non-relevant information. Not present in Version 2. MANRoutingCode Message.InterfaceInfo.RoutingCode DuplEmission Message.NetworkInfo.IsPossibleDuplicate OrigSenderReference Not used by Alliance Access. Not present in Version 2. MessageOrigin {PDUType}.MessageCreator Modified {PDUType}.IsMessageModified OriginalRelatedMessage {PDUType}.IsRelatedInstanceOrigin ReportingApplication {PDUType}.ReportingApplication BackToNonOriginator Not used by Alliance Access. Not present in Version 2. DuplEmission {PDUType}.NetworkInfo.IsPossibleDuplicate Network DeliveryReport.NetworkInfo.Network NetworkAttribute The subfields of this composite element are mapped to both DeliveryReport.NetworkInfo, and DeliveryReport.Message.SecurityInfo. Check the details of NetworkAttribute below. NetworkSessionNr DeliveryReport.NetworkInfo.SessionNr NetworkSeqNr DeliveryReport.NetworkInfo.SeqNr ReceiverDeliveryStatus DeliveryReport.ReceiverDeliveryStatus Interventions DeliveryReport.Interventions System Management Guide Appendix D - Message Formats Used in AI Version 1 Type/Element TransmissionReport Version 2 Mapping Network TransmissionReport.NetworkInfo.Network NetworkAttribute The subfields of this composite element are mapped to both TransmissionReport.NetworkInfo, and TransmissionReport.Message.SecurityInfo. Check the details of NetworkAttribute below. NetworkSessionNr TransmissionReport.NetworkInfo.SessionNr NetworkSeqNr TransmissionReport.NetworkInfo.SeqNr NetworkDeliveryStatus TransmissionReport.NetworkDeliveryStatus Interventions TransmissionReport.Interventions IntvCategory Intervention.InterventionCategory CreationTime Intervention.CreationTime ApplicationOrigin Redundant information, also present in Text. Not present in Version 2. OperatorOrigin Intervention.OperatorOrigin Text Intervention.Contents SigningRequired Message.SecurityInfo.IsSigningRequested SignerDN Message.SecurityInfo.SWIFTNetSecurityInfo.SignerDN SecurityAttribute SWIFTNetSecurityAttribute Message.SecurityInfo SWIFTNetResponseAttribute ResponderDN NetworkInfo.SWIFTNetNetworkInfo.Response ResponderDN NonRepType Message.SecurityInfo.SWIFTNetSecurityInfo.Response NRType Although the enum type name is different in the schema (NonRepType in Version 1, NRType in Version 2), the enum values stay the same. NonRepWarning Message.SecurityInfo.SWIFTNetSecurityInfo.Response NRWarning ResponseRef NetworkInfo.SWIFTNetNetworkInfo.ResponseSWIFT Ref SwiftResponseRef NetworkInfo.SWIFTNetNetworkInfo.ResponseSNLRef CBTReference NetworkInfo.SWIFTNetNetworkInfo.Response Reference DuplCreation NetworkInfo.SWIFTNetNetworkInfo.ResponseIs PossibleDuplicateResponse ValidationDescriptor NetworkInfo.SWIFTNetNetworkInfo.ResponseValidation Descriptor AuthResult Message.SecurityInfo.SWIFTNetSecurityInfo.Response SignatureResult AuthValue Message.SecurityInfo.SWIFTNetSecurityInfo.Reponse SignatureValue Intervention SWIFTNetSecurityAttribute 15 July 2011 531 Alliance Access 7.0.20 Version 1 Type/Element SWIFTNetRequestAttribute Version 2 Mapping RequestorDN Message.Sender.DN ResponderDN Message.Receiver.DN Service NetworkInfo.Service RequestType Message.MessageIdentifier NRIndicator Message.SecurityInfo.SWIFTNetSecurityInfo.IsNR Requested NonRepType Message.SecurityInfo.SWIFTNetSecurityInfo.NRType NonRepWarning Message.SecurityInfo.SWIFTNetSecurityInfo. NRWarning SwiftRef NetworkInfo.SWIFTNetNetworkInfo.SWIFTRef SwiftRequestRef NetworkInfo.SWIFTNetNetworkInfo.SNLRef CBTReference NetworkInfo.SWIFTNetNetworkInfo.Reference SNLEndPoint NetworkInfo.SWIFTNetNetworkInfo.SNLEndPoint SnFQueueName NetworkInfo.SWIFTNetNetworkInfo.SnFQueueName SnFInputTime NetworkInfo.SWIFTNetNetworkInfo.SnFInputTime SnFPDMHistory NetworkInfo.DuplicateHistory ValidationDescriptor NetworkInfo.SWIFTNetNetworkInfo.Validation Descriptor AuthResult Message.SecurityInfo.SWIFTNetSecurityInfo.Signature Result AuthValue Message.SecurityInfo.SWIFTNetSecurityInfo.Signature Value FormatAttribute FormatAttributeMX Was reserved for future use in Version 1. Not present in Version 2. NetworkAttribute SWIFTNetRequestAttribute The subfields of this composite element are mapped to both NetworkInfo and Message.SecurityInfo. Check the details of SWIFTNetRequestAttribute below. SWIFTNetResponseAttribute The subfields of this composite element are mapped to both NetworkInfo and Message.SecurityInfo. Check the details of SWIFTNetResponseAttribute below. CBTApplication {PDUType}.InterfaceInfo.MessageCreator See note 4. MessagePartner Non-relevant information. Not present in Version 2. SessionNr Non-relevant information. Not present in Version 2. SeqNr Non-relevant information. Not present in Version 2. TargetApplicationRule RoutingInstruction.RoutingFunction See note 5. TargetRoutingPoint RoutingInstruction.RoutingPoint MessageOrigin TargetApplication 532 System Management Guide Appendix D - Message Formats Used in AI Version 1 Type/Element LogicalReply Address AddressFullName Version 2 Mapping SenderReference MessageStatus.SenderReference SuccessIndication MessageStatus.IsSuccess ErrorText MessageStatus.ErrorText Nickname AddressInfo.Nickname FullName AddressInfo.AddressFullName In Version 2, when using FullName, you must also specify either the BIC12, the DN, or the Nickname. X1 AddressFullName.X1 X2 AddressFullName.X2 X3 AddressFullName.X3 X4 AddressFullName.X4 FinancialInstitution AddressFullName.FinancialInstitution BranchInformation AddressFullName.BranchInformation CityName AddressFullName.CityName Location AddressFullName.Location CountryCode AddressFullName.CountryCode Notes 1. The enumerated type 'OrigMessageFields' has been renamed to 'MessageFields' with the following mapping: Version 1 Value Version 2 Value NoOriginal NoOriginal Minimum MinimumInfo Condensed HeaderOnly Full HeaderAndBody Expanded NA 2. The enumerated type 'TransmissionNetwork' has been renamed to "Network'" with the following mapping: Version 1 Value Version 2 Value ApplicationNetwork Application SwiftNetNetwork SWIFTNet OtherNetwork Other 3. The enumerated type 'DispositionState' has been renamed to 'RoutingStep' with the following mapping: 15 July 2011 Version 1 Value Version 2 Value Verify Verify 533 Alliance Access 7.0.20 Version 1 Value Version 2 Value Authorise Authorise Modify Modify Ready ReadyToSend 4. The enumerated type 'CBTApplication' has been renamed to 'MessageCreator' with the following mapping: Version 1 Value Version 2 Value ApplicationInterface ApplicationInterface SwiftnetInterface SWIFTNetInterface MessageEntry Workstation MessengerAdapter Messenger Other Other 5. The enumerated type 'TargetApplicationRule' has been renamed to 'RoutingFunction' with the following mapping: D.6 Version 1 Value Version 2 Value InternalRouting Route CBTApplication DisposeToRoutingStep RoutingPoint DisposeToRoutingPoint MQ-MT Format Introduction The following sections describe the structure of message in MQ-MT format. D.6.1 Structure of a Message in MQ-MT Format Description of elements In the following table, the columns From, To, and To (Resp) indicate whether Alliance Access requires an element to process a message successfully. The columns represent the following: • From - a message request that Alliance Access receives from a message partner • To - a notification, a system message, or a message request that Alliance Access sends to a message partner. • To (Resp) - a response message that Alliance Access sends to a message partner. When an WebSphere MQ message is sent in MQ-MT format, it has the following elements in the Message Data part. The elements that Alliance Access requires are marked as Mandatory 534 System Management Guide Appendix D - Message Formats Used in AI (M). If an element is marked Optional (O) and has a non-null value, then Alliance Access processes it: Elements in MQ-MT message Element UUMID Description The UUMID of the message. Present if the option Transfer UUMID is selected in the message partner profile. Type String (45 bytes) padded with spaces From To To (Resp ) O O O Message The business data that is being MQMTMessage exchanged between applications. This can contain the one of the types of information, as outlined in "MQMTMessage" on page 536. M M O OriginalMessage A FIN message, with an optional block 4. (1) -- O -- The field contains the offset -in block 4 that caused the error, as follows: -- O FIN message Block 4 is included if Send original message has one of the following values in the message partner profile: • When created by another Message Partner • When message modified • Always ValidationErrorC ode The error code that applies if the requested level of message validation has failed. Present if: • an error is reported during message processing (Feedback element in the MQ Message Descriptor does not contain MQFB_PAN), and {REP:{ERR: (<error_information>)} } <error information> is a string, such that: <error_code> - <error explanation> at offset <offset> • Transfer Validation Code is selected in the message partner profile. 15 July 2011 535 Alliance Access 7.0.20 Element S-Block Description Present if: • Transfer SAA Information is selected and Use MQ Descriptor is not selected Type From S-Block See "Codes in the Trailer (Block S)" on page 538 and "Routing Code Trailer" on page 541. O To O To (Resp ) -- • Add Routing Code is selected. (1) The blocks 1, 2, 3, and 5 are always present. D.6.2 MQMTMessage Overview The MQMTMessage part of the Message Data in a WebSphere MQ message carries the business data that is being exchanged between Alliance Access and an application. The MQMTMessage part can carry the information of the following type: • SWIFT Output Message • Transmission Notification • Delivery Notification • Information Notification • History Notification • System Delivery Notification Message Request A message request is carried in the FIN Output message. Transmission Notification Alliance Access uses the Message Data part of WebSphere MQ to store information related to the transmission notification and optionally, on the original message. (an option in the message partner profile). The Feedback element only has meaning for a report message (MQ Report/Reply). To check the status of a message, you must check the content of the ACK. Delivery Notification When you create a message, you can request that the progress of your message is monitored. This results in Alliance Access receiving a message about the message delivery, which can be reconciled with the original message. In such cases, creates a Delivery Notification. The Delivery Notification contains a reference to the original message through the CorrelId field of WebSphere MQ Descriptor. The text of the original message can be appended to the Delivery Notification. 536 System Management Guide Appendix D - Message Formats Used in AI Information Notification Alliance Access uses the Message Data part of WebSphere MQ to store data that is related to the Information notification and optionally on the original message. The Information notification has a structure which resembles a SWIFT ACK message, and it can contain a block S. Block 1 contains INF instead of the F21 to indicate this is an Information Notification, the sender logical terminal code, followed by "0000" for the SWIFT session number, and "000000" for the SWIFT sequence number. There is no block 2. Block 4 does not contain a CrLf at the beginning. The following tags have been defined inside block 4: TAG Description DAT The date and time of the information notification in the format YYYYMMDDHHMMSS. The date is the Co-ordinated Universal Time (UTC), which is the time standard the operating system uses. CAT The information notification category. The following are defined: 00-None illegal value of the intervention 01-Routing generated by the creation or routing of a message 02-Security security related. For example, bypass of authentication 03-NetworkReport generated when transmitting to a network 04-DeliveryReport generated by traffic reconciliation 05NetworkFormattedTransmitted a network-formatted transmitted intervention 06-NetworkFormattedReceived a network-formatted received intervention 07-MessageModified intervention contains safe store of a message text which has been modified 08-MessageScissored scissors and broadcast related 09-Other all other types of intervention n-Unknown (n > 9) unknown intervention category NAM The information notification name. Alliance Access does not offer a fixed list of these. However, some examples are "Instance routed", "Message Processed", "Report text", and "User delivery report". TXT The information notification text. OPR The name of the operator. History Notification Alliance Access uses the Message Data part of WebSphere MQ to store data that is related to the History notification and optionally on the original message. The History notification contains the last 10 interventions of a message. The History notification has a structure which resembles a SWIFT ACK message, and it can contain a block S. 15 July 2011 537 Alliance Access 7.0.20 Block 1contains HIS instead of the F21 to indicate this is a History Notification, the sender logical terminal code, followed by "0000" for the SWIFT session number, and "000000" for the SWIFT sequence number. There is no block 2. Block 4 does not contain a CrLf at the beginning. The tags have been defined inside block 4 for a History notification as for an Information Notification. System Message A Delivery Notification System Message is of the following messages MT 010, MT 011, MT 012, MT 015, or MT 019. Alliance Access sends it to an application in a FIN Output message. A system message contains a SWIFT block 1, 2, and 5. The block S of the system message offers the same trailers as a SWIFT output message. The block S can include a SYS tag. The CON and TRN tags are optional in a System Message. System messages have a WebSphere MQ priority 7. Important D.7 If System Messages are sent to WebSphere MQ, then it is possible that the System Messages are delivered before the Transmission Notification for the corresponding message. This happens when the system messages have a higher priority within Alliance Access than the transmission notifications. SWIFT recommends that applications which use the Traffic Reconciliation within Alliance Access ensure that Delivery Notifications are delivered before the Transmission Notifications. Codes in the Trailer (Block S) Overview If trailers are present, then they are included in block S. This section describes the various kinds of trailers that exist and lists possible tags. D.7.1 Authentication Result Trailer Overview When the received message requires an Authentication trailer, Alliance Access generates the Authentication Result trailer. The following tags indicate the result of the authentication: Tag Meaning SAC Successfully authenticated and authorised. Present if both the following conditions are met: • signature verification was successful • RMA authorisation verification was successful SAB Authentication and/or authorisation bypassed. Present if any of the following conditions are met: • signature verification failed but authentication was bypassed 538 System Management Guide Appendix D - Message Formats Used in AI Tag Meaning • RMA authorisation verification failed but was bypassed SAI Authentication and/or authorisation incorrect. Present if any of the following conditions are met: • signature verification failed • RMA authorisation verification failed Note D.7.2 If the message to be transferred to the back-office application is PAC2-equivalent PKI-signed, then the verification result is passed with the message in block S. This does not apply to connection methods that use the MERVA/2 data format). Proprietary Authentication Result Trailer Overview The Proprietary Authentication Result trailer is generated by Alliance Access. It is always present when the received message requires a Proprietary Authentication trailer. The following tags indicate the result of the Alliance Access authentication compared to the Proprietary Authentication trailer value (PAC). Tag Meaning FAC Successfully authenticated. Present if both the following conditions are met: • signature verification was successful • PAC authentication (if present) was successful using the current key FAB Proprietary Authentication bypassed. Present if either the following conditions are met: • signature verification failed but authentication was bypassed • PAC authentication (if present) failed but was bypassed FAI Proprietary Authentication incorrect. Present if either the following conditions are met: • signature verification failed • PAC authentication (if present) failed D.7.3 Local Authentication Trailer Overview The Local Authentication trailer may be appended to messages exchanged between Alliance Access and a message partner. The message partner profile must be set up to activate the Local Authentication feature. The only tag for this trailer is LAU. The associated value is the SA2 value (eight hexadecimal characters) resulting from the authentication calculation. 15 July 2011 539 Alliance Access 7.0.20 Example {LAU:A54ECB89} D.7.4 Alliance Access Instance Information Trailer Overview The Alliance Access Instance Information Trailer may be appended to messages that Alliance Access exchanges with a message partner when the WebSphere MQ connection method is used. The instance information is included if the following options are configured in the message partner profile as follows: • The Transfer SAA Information option is selected. • The data format MQ-MT is selected. • The Use MQ Descriptor option is not selected. Parameters in block S for instance information The following tags include the information about the Alliance Access instance: D.7.5 Tag Size Meaning INS 8 bytes The name of the Alliance Access instance which sends the message and the name of the Alliance Access queue where the message was stored. UNT 25 bytes The Alliance Access Unit to which the message belongs USR 20 bytes The OS user that runs the Alliance Access server Alliance Possible Duplicate Overview The Alliance Possible Duplicate trailer is an optional trailer appended by Alliance Access. It indicates to the external interface receiver of the message that the message may have been delivered several times. The only tag for this trailer is SPD. Example {SPD:} D.7.6 Transaction Reference Number Trailer Overview The Transaction Reference Number trailer can be present when the File Transfer connection method is used, if the message partner is configured with direction "From and To". The Transaction Reference Number trailer is appended when a notification is returned to the originator without block 4 information (text of the original message). In this case, 'originator' means the same message partner that received and processed the original message. The only tag for this trailer is TRN. The associated value comes from field 20 in the message text. 540 System Management Guide Appendix D - Message Formats Used in AI Example {TRN:<trn-value>} Note D.7.7 The generation of a {TRN:<trn-value>} trailer always implies the presence of a {CON:} trailer. Condensed Trailer Overview The Condensed trailer is used for batch output format RJE, and DOS-PCC. This trailer is appended when a notification without block 4 information (text of the original message) is sent to an external entity. The only tag for this trailer is CON. Example {CON:} D.7.8 Copy Trailer Overview The Copy trailer is used for batch output formats RJE, DOS-PCC, and MERVA/2. This trailer may be appended to messages by Alliance Access. If present, it indicates that the message is either a primary copy (original message) or a secondary copy (copy of a message). There are two tags for this trailer: D.7.9 Tag Meaning COP:P Message is a primary copy COP:S Message is a secondary copy Routing Code Trailer Overview The Routing Code trailer is used to transmit routing information to message partners. The content of the routing_code field and the disposition_address_code field is controlled by the value of the configuration parameter RTV Routing. For more information, see page 165. The Routing code transmitted check box in a message partner profile controls the transmission of the Routing Code trailer to a message partner. This check box can be selected only from an Alliance Workstation. If the Routing code transmitted check box is not selected, then only the following information is transmitted: • For CAS 2 message partners, the routing code is transmitted in the ManRoutingCode field. If the message has been retrieved, then the NetworkRetrieved field is set. • For RJE message partners, the {RTV:} trailer is transmitted. 15 July 2011 541 Alliance Access 7.0.20 If the Routing code transmitted check box is selected, the above information is transmitted, along with the following: • The routing code is transmitted in the {MAN:<RoutingCode>} trailer. • The disposition address code is transmitted in the {DAC:RTV} trailer. 542 System Management Guide Appendix E - Message Validation and Disposition Appendix E Message Validation and Disposition Overview This section describes how Alliance Access validates and disposes messages in the Application Interface. This section describes the message validation and disposition process first for messages that do no use the CAS format, and then, for messages in the CAS format. E.1 Message Validation and Disposition Overview Description Message disposition provides the means to either "hold and check" messages arriving from a particular message partner, or to forward the messages using the routing rules set at the Application Interface Inbound queue. The default disposition for all message formats is specified in the following places: • For automatic input sessions: the Reception tab of the message partner profile. • For manual input sessions: the Start Session or Run Session window. If you require no restriction on message disposition, then select Route from the Disposition option in the Reception tab. To dispose messages into a particular message preparation queue, then select: 1. Dispose from the Note Disposition option in the Reception tab. The message preparation queues which are available to a particular message partner depend upon the permission to bypass certain stages in the message preparation sequence. For instance, if the R7.0_MsgPartner profile permits the message partner to bypass Verification but not Authorisation, then the message may skip Verification and be disposed to the Authorisation queue. 2. The field Message In appears. Click the field to display a list of available message preparation queues. 3. Select one of the following queues, as appropriate: – Modification (_MP_mod_text) – Verification – Authorisation – Ready-to-send Validation and message disposition The following formats of messages influence the message validation and disposition process: • Messages in the CAS format 15 July 2011 543 Alliance Access 7.0.20 In addition to settings in the message partner and permission profile, CAS messages may contain information governing the disposition of the message. • Messages in non-CAS format For non-CAS messages, the Application Interface uses the result of validation checks combined with the settings in the message partner profile and permission profile to dispose the message. Operator profile for a message partner Each message partner profile has an associated operator profile, specified in the Profile Name field of the Reception tab. The profile that is associated with the message partner controls the activities that the message partner is permitted to perform. Specifically, the profile is a collection of rules that Alliance Access uses to govern how to dispose a message that received from a back-office application. This profile entitles the message partner to create messages in Alliance Access. A default operator profile, R7.0_MsgPartner, is available for use with message partners. Note To use the Dispose function for received messages, the operator profile that is associated with the message partner must include the action Dispose Message for the Application Interface application. By default, this action is already selected in the default profile, R7.0_MsgPartner. R7.0_MsgPartner When Alliance Access is installed, each message partner receives the default operator profile R7.0_MsgPartner. The default permissions in the R7.0_MsgPartner profile can be changed to suit the business activities of your site. It specifies no constraints on the setting of the following attributes: • Destinations allowed to create messages • Message Types (MTs) that are accepted by the message partner • Currencies used • Permission to bypass message verification • Permission to bypass message authorisation • Permission to "dispose" a message directly to a routing point E.2 Levels of Validation Purpose After the Application Interface passes the message to the routing software, a check is made to see whether message text validation must be applied. Alliance Access applies a generic message validation and extraction process to messages that it receives from a message partner in Network Dependent Format (NDF), to ensure that the message is syntactically and semantically correct. This validation involves a structural checking and extraction of all message blocks (1, 2, 3, 4 and 5), as well as a block content validation (excluding the message text block, that is, block 4). This is the absolute minimum requirement for a message to be added to the Alliance Access 544 System Management Guide Appendix E - Message Validation and Disposition database. If Alliance Access finds that the structure and the content of these blocks are syntactically incorrect, then the message fails validation. In this case, an event is logged in the Event Journal and then message is discarded from the system. Alliance Access closes the session that was responsible for delivering the message. The generic check does not validate the contents or structure of the text block. Note You must choose carefully the validation level to use. For instance, you can select Minimum validation for the batch input of messages that are prepared on your mainframe because the source of them is known. However, you can select Medium validation for the batch input of messages from an obscure or infrequent source, as the risk is greater. Validation levels and uses The Validation level field offers the following options for validation of the text block of a message (the default is Medium): Validation level Description No Validation Alliance Access does not parse or validate the message, and as a result, keywords are not extracted. If you want to route messages based on routing keywords, such as the transaction reference number (TRN), then do not select No Validation. Minimum Alliance Access performs the validation and extraction of some keywords, like currency, value, amount, value date, the field MF20, and so on. Medium Alliance Access performs a syntactical validation at the field level. It checks for the presence of mandatory fields, keyword validation, limits, ranges of values, and so on. If a message fails Medium validation during an Interactive session, then a negative reply is generated and sent to the message partner. Maximum Important This level is provided to allow for a possible future level of message validation. Today this level performs the same checks as Medium validation. When the validation level is set to No validation, no keywords are extracted. To route FIN messages based on the Transaction Reference Number (TRN) keyword, you must specify at least Minimum as the validation level. However, if the validation level is set to No validation and if you have configured Alliance Access to generate the message UUMID for FIN messages from the Transaction Reference Number (TRN), then Alliance Access performs a simple syntactic search on Block 4 and extracts the content of the first field 20, or any variation of field 20 (for example, 20C). If the field is 20C, then Alliance Access also extracts the first subfield, and the TRN may appear in the UUMID but you cannot route on the TRN. If the field content has more than 16 characters, then the TRN is not added to the UUMID. When you install a Message Syntax Table, you can configure Alliance Access to generate the message UUMID from the Transaction reference number. Validation of messages in CAS format If the format of the received message is CAS Network Independent Format (NIF), then no generic check is applied. The messages that are received using the CAS protocol have a field in the APDU minValidation that specifies the validation level that is requested for the message. If a value for 15 July 2011 545 Alliance Access 7.0.20 this field is present, then it overrides the setting of the Validation level field. If no value is present in this field, then the value of the field is used. Calculation of common reference If the configuration parameter Common Ref Calculation is set to No, then Alliance Access does not calculate the Common Reference in field 22. In this case, the Validation level is ignored and a NAK may be received if field 22 of the message contains incorrect information. E.3 Message Validation for RJE, DOS-PCC, and MERVA/2 Messages Overview Validation of these messages starts with the syntactical check that Alliance Access performs on the basic block structure of the message. Alliance Access uses the Validation level is specified in the Reception tab of the message partner profile. If the block structure of the message is found to be syntactically incorrect, then Alliance Access completes the message and store it in the database with format internal. If the block structure is syntactically correct, then the level of validation requested on the text block (block 4) is checked, as follows: • If the check reveals that minimum validation was requested, then the message is proved acceptable. • If the check reveals that intermediate validation of the text block was requested but has failed at this level, then the message is proved unacceptable and is rejected. However, if Message modification in the message partner profile is set to Allowed, then Alliance Access moves the message to the text modification queue (_MP_mod_text). This allows an operator with the appropriate permissions to modify the message. • The maximum validation level is not implemented in this version. If selected, intermediate validation is imposed. Checks after message is acceptable If the validation checks prove that the message is acceptable, then Alliance Access checks the following in the operator profile that is associated with the message partner profile: • Does the message partner have the permission to create a message? • Is the specified destination permitted (own destinations)? • Is the specified message type permitted? • Is the specified currency allowed? The operator profile is specified in the Profile Name field of the Receptiontab. If any of these validation checks fail, then the message is rejected and completed. 546 System Management Guide Appendix E - Message Validation and Disposition If the result of each check is positive, then Alliance Access checks the value of the Routing files in the Receptiontab, and performs one of the following actions: • Dispose: routes the message according to the bypass permissions that are preset in the message partner profile. See the section, "Routing based on bypass parameters" on page 547. • Route: routes the message to the preferred network interface of the correspondent. Note To use the Dispose function for received messages, the operator profile that is associated with the message partner must include the action Dispose Message for the Application Interface application. By default, this action is already selected in the default profile, R7.0_MsgPartner. Routing based on bypass parameters E.4 Bypass Verification Bypass Authorisation Route Message To No No Verification Queue No Yes Verification Queue Yes No Authorisation Queue Yes Yes Preferred network interface of correspondent Message Validation for XML Messages Overview For XML messages (file format XML), the payload must be compliant with the Standards XML structure, and contain the <Document> element. Any XML message for which no corresponding MX standard is installed in Support is rejected. This does not apply to messages in the AnyXML format, which are only validated as being a well-formed XML document. There is no validation of the content of the payload in either format. Checks after message is acceptable If the validation checks prove that the message is acceptable, then Alliance Access checks the following in the operator profile that is associated with the message partner profile: • Does the message partner have the permission to create a message? • Is the specified destination permitted (own destinations)? • Is the specified SWIFTNet Service permitted? The operator profile is specified in the Profile Name field of the Receptiontab. If any of the checks fail, then the message is rejected and completed. If the result of each check is positive, then Alliance Access routes the message to the _SI_To_SWIFTNet queue. In this case, Alliance Access does not check the the bypass permissions that are preset in the message partner profile. 15 July 2011 547 Alliance Access 7.0.20 E.5 Message Validation for CAS Messages Overview This section describes how Alliance Access validates messages that are in CAS format. E.5.1 Overview of Message Validation for Messages in CAS Format Overview CAS messages do not undergo the block and syntactical checks that are applied to non-CAS messages for SWIFT format (NDF). Only the validation requested on the text block (block 4) is checked. Validation on text block The validation requested on the text block (block 4) is checked, as follows: 1. If the validation of the text block failed, then the message is rejected. However, if the message partner profile or relevant APDU field states that the message is modifiable, then the message is moved to the text modification queue (_MP_mod_text). 2. 3. Validation level Validation checks and results Minimum If the check reveals that minimum validation was requested, then the message is proved acceptable. Intermediate If the text block was requested but has failed at this level, then the message is rejected. However, if the message partner profile or relevant APDU field states that the message is modifiable, then the message is moved to the text modification queue (_MP_mod_text). Maximum The maximum validation level is not implemented in this release. If it is selected, then the Alliance Access applies intermediate validation. Messages the Alliance Access receives using the CAS protocol have an optional field in the APDU minValidation that specifies the validation level for the message. When a value for this field is present, it overrides the setting of the Validation Level button in the message partner profile. If no value is present in the APDU field, then the value of the button is taken. Warning If the APDU minValidation is set, then minimum validation on the message is carried out, that is, the message is accepted. Checks after message is acceptable If the validation checks prove that the message is acceptable, then Alliance Access considers the settings in both the message APDU fields. Alliance Access also checks the operator profile that is associated with the message partner profile, to manage the disposition of the message. In addition, a message in CAS NDF or CAS NIF format is disposed according to a combination of the following APDU fields: • targetApplication 548 System Management Guide Appendix E - Message Validation and Disposition targetApplicationRule targetRoutingPoint • networkAttribute networkApplicationName networkPart1 networkPart2 networkPart3 • dispositionState The subfield networkApplicationName specifies the communication interface responsible for handling the message, that is, Application Interface or SWIFT Interface. Depending on the interface specified, the fields networkPart1, networkPart2 and networkPart3 identify the message partner, the sending or receiving logical terminal for SWIFT Interface, as follows: networkApplicationName networkPart1 networkPart2 networkPart3 applicationInterface MAPID - - swiftInterface Sending logical terminal Receiving logical terminal - For a more details explanation of how the combination of these fields are used to route messages in CAS format see: • "Disposition based on APDU fields" on page 549 • "Disposition Actions for Messages in CAS Format" on page 550 Disposition based on APDU fields Basically, Alliance Access performs four sequential checks on the APDU fields, to determine how to dispose the message that is in CAS format: 1. Is internalRouting specified in the field labelled targetApplicationRule? If yes, Alliance Access checks the permissions of the operator profile that is associated with the message partner profile, and if acceptable, the message is created and routed according to the routing rules at the inbound queue of the Application Interface. Note 2. Alliance Access does not changed whether the message partner has the permission to bypass verification and authorisation. Is the term routingPoint specified in the field targetApplicationRule, and does the field labelled targetRoutingPoint request a particular routing point in Alliance Access? If yes, then it is important that the requested routing point exists. Alliance Access checks the permissions of the operator profile that is associated with the message partner profile to determine whether the message partner has the "Dispose" function assigned to it. If yes, then the message is moved to the requested routing point. This must be an "allowed target routing point" or an exit point as specified in System Management Application (SMA). No other checks are carried out. 15 July 2011 549 Alliance Access 7.0.20 3. Is the term cBTApplication specified in the field targetApplicationRule, and is the disposition state of the message specified in the field labelled dispositionState? The available values for dispositionState include: • Fix. This value indicates the message must be sent to the text modification queue. No checking of the permission profile is performed except the permission to modify a message. Permission to modify a message may be specified in either the message partner profile or the message APDU field modifyAllowed. A specification in the APDU takes precedence. • Verify. This value indicates that the message must be sent to the Verification queue. No checking of the permission profile is performed except the permission to create a message. • Authorise. This value indicates that the message must be sent to the Authorisation queue. The permission for bypass verification is checked. If the permission is set, then the message is routed to the Authorisation queue. If the permission is not set, then the message is routed to the Verification queue. • Ready. This value specifies routing according to the application specified in the field networkApplicationName. If cBTApplication is specified in the field labelled targetApplicationRule, then networkApplicationName will specify the Alliance application as either swiftInterface or applicationInterface.The permissions for bypass authorisation and bypass verification are checked. • Cancel. The message is completed. • For the SWIFT Interface Application (SIA), the message is routed to the _SI_to_SWIFT queue. • For the Application Interface, the message is routed to the first exit point assigned to the message partner specified as MAPID in networkPart1. 4. If none of the previous three checks apply, and the message is in input format then AI attempts to route the message as far as it can, based upon the default disposition or routing settings in the message partner profile and the permissions set in the permission profile, thus: • If the permission for bypassing verification is not set, then the message is directed to the Verification queue. • If the permission for bypassing authorisation is not set, then the message is directed to the Authorisation queue. • If the message is in the SWIFT format and both of the above permissions are set, then the message is routed to the SI_to_SWIFT queue. In all other cases, the message is completed. E.5.2 Disposition Actions for Messages in CAS Format Overview Alliance Access moves the received messages in the CAS network-independent format (NIF) according to the combination of values for: • dispositionState • targetApplicationRule 550 System Management Guide Appendix E - Message Validation and Disposition • networkApplicationName dispositionState networkApplicationName Permissions or message partner profile settings Action omitted or any valid omitted value omitted or applicationInterface or swiftInterface not applicable according to default disposition set in message partner profile or Run Session or Start Session window cancel cBTApplication omitted or applicationInterface or swiftInterface not applicable complete the message fix cBTApplication omitted or applicationInterface or swiftInterface not applicable send to _MP_mod_text queue verify cBTApplication omitted or applicationInterface or swiftInterface not applicable send to _MP_verificatio n queue authorise cBTApplication omitted or applicationInterface or swiftInterface No permission to bypass Verification on Msg Type or Currency code given send to _MP_verificatio n queue authorise cBTApplication omitted or applicationInterface or swiftInterface Permission to bypass Verification on Msg Type and Currency code is given send to _MP_authorisat ion queue ready cBTApplication omitted or applicationInterface or swiftInterface No permission to bypass Verification on Msg Type or Currency code is given; and No permission to bypass authorisation on Msg Type or Currency code given. send to _MP_verificatio n queue applicationInterface Permission to bypass Verification on Msg Type and Currency code is given. and Permission to bypass Authorisation of Msg Type and Currency code is given. send to first exit point assigned in the MP profile swiftInterface Permission to bypass Verification on Msg Type and send to _SI_to_SWIFT queue 15 July 2011 targetApplicationRule send to _MP_authorisat ion queue 551 Alliance Access 7.0.20 dispositionState targetApplicationRule networkApplicationName Permissions or message partner profile settings Action Currency code is given. and Permission to bypass Authorisation of Msg Type and Currency code is given. omitted or any valid internalRouting value ignored omitted or applicationInterface or swiftInterface route according to defined routing omitted or any valid cIFPreferred value ignored omitted or applicationInterface or swiftInterface route according to settings made in the Correspondent Information File omitted or any valid routingPoint value ignored omitted or applicationInterface or swiftInterface 552 Permission to move messages is given move to the routing point specified in targetRoutingPoi nt System Management Guide Appendix F - Connection Methods in AI Appendix F Connection Methods in AI Introduction Connection methods define how messages are exchanged between Alliance Access and message partners. Note F.1 For Alliance Workstation, all Interactive sessions are run on the server machine. Direct FileAct Overview This section provides information about the Direct FileAct connection method that you can use to transfer a payload file between Alliance Access and a back-office application. The core design of the Direct FileAct adapter is a mapping between a directory with a correspondent for a given service. This configuration is primarily suited to handle a limited number of correspondents with a few services, to keep the number of directories to manage under control. F.1.1 Description of Direct FileAct Direct FileAct Direct FileAct is an adapter on Alliance Access that enables the transfer of a payload file (of up to 250 MB in size) between Alliance Access and a back-office application. No XML version 2 message or parameter file with FileAct settings accompanies the payload file. Direct FileAct makes it easy to integrate back-office applications which already produce payload files with Alliance Access because no specific development effort is required to define the transmission parameters in an XML version 2 message. It is intended for use when files are transferred to a limited number of pre-defined correspondents. 15 July 2011 553 Alliance Access 7.0.20 Direct FileAct connection method Access Payload Directory ... File MP 2 Back Office - Responder DN A - Service - ... - Responder DN B - Service - ... Directory ... MP 3 SWIFTNet Interface Correspondent A Correspondent B - Responder DN C - Service - ... Directory ... Direct FileAct Message Partners Correspondent C D0540185 MP 1 Configuration of Direct FileAct A message partner profile with the Direct FileAct connection method must exist for each backoffice application and correspondent that will use Direct FileAct to transmit files between each other. For example, if the back-office application stores a payload file in a pre-configured input directory, then the presence of the file in the directory can automatically start a Direct FileAct session. In this case, Alliance Access determines the FileAct transmission parameters from the message partner that is associate with the directory. You can define and view a message partner profile for Direct FileAct only through the Alliance Access Configuration package on the Alliance Web Platform. A Direct FileAct transfer session can be started automatically or manually. For a manual transfer, an operator can manually select the payload file to send to SWIFTNet. License option on Alliance Access Use of the Direct FileAct connection method requires the licence package, 22:DIRECT FILEACT. F.1.2 Features of Direct FileAct Directory Mapping The Direct FileAct adapter establishes an association between a set of directories and a FileAct correspondent. 554 System Management Guide Appendix F - Connection Methods in AI Digest Calculation Alliance Access calculates the digest of each payload file that it receives from a back-office application and store the digest value in the database. The configuration parameter File Digest Algorithm specifies which Secure Hash Algorithm (SHA-1 or SHA-256) to use to calculate the digest value. Duplicate detection Alliance Access does not verify whether the payload file that a Back Office sends is a duplicate. However, Alliance Access can detect duplicate FileAct messages based on the file-digest calculation that it applies to an internal File message. The SWIFTNet Interface Component (SNIS) creates an internal message of type File for every Direct FileAct transfer, to help manage the file transfer to and from the back-office application. Polling Timer The configuration parameter Automatic - Polling Timer controls the frequency at which Alliance Access automatically scans the Direct FileAct Input directories to find files sent from a back-office application. Notifications of transmission and delivery For files that are sent from a back-office application to SWIFTNet, Alliance Access provides an empty file of the same name and with an additional extension that indicates the status of a file transmission. The response file is empty and the back-office application does not need to parse it. Only the extension of the file is relevant. For more information about Direct FileAct response files, see "Direct FileAct Transmission Status" on page 560. Alliance Access sends delivery notifications only in store-and-forward mode and if specifically requested in the Emission profile associated with the Requestor DN. No Local Authentication support The Direct FileAct adapter does not support the configuration of Local Authentication settings to secure payload files that are sent to or received from a back-office application. If a back-office application requires the payload files to be secured by Local Authentication, then you can use the File Transfer connection method instead. No File Compression The Direct FileAct adapter does not compress the payload files. Payload files must no exceed 250 MB in size. No T-Copy or Y-Copy support The Direct FileAct adapter does not support Y-Copy and T-Copy modes. Therefore, you cannot use Direct FileAct for a service for which Y-Copy or T-Copy are defined as mandatory in their Application Service Profiles. At the start of every Direct FileAct message partner session, Alliance Access checks the associated FileAct service configuration, and stops the session if the service is configured for TCopy or Y-Copy mode. 15 July 2011 555 Alliance Access 7.0.20 Direct FileAct versus File Transfer The following table gives a summary the difference between Direct FileAct and File Transfer connection methods: Feature Direct FileAct File Transfer Configuration of bi-directional exchange: Allowed direction parameter set to To & From Message Partner No Yes Manual and automatic start of transfer sessions Yes Yes One directory per correspondent on Alliance Access to hold payload files that the back-office application sends and receives Yes Yes Limited number of correspondents Yes No XML version 2 message that accompanies the payload file No Yes Message partner profile, specific to each correspondent Yes No Selection of the payload file during a manual start of a transfer session Yes No Requires a specific licence package Yes No Requires specification of data formats used to transfer information No Yes Local Authentication setting to secure the payload files No Yes Support of the HeaderInfo element for services that mandate its usage No Yes FileAct transmission settings provided through: F.1.3 Direct FileAct from the Back Office Before a file can be transmitted to SWIFTNet The description of "Emission of a file to SWIFTNet" on page 557 assumes that: • A "From" message partner with the Direct FileAct connection method has been defined for the back-office application. • The data directory where the back-office application will store files for sending to SWIFTNet has been defined and with correct access permissions. • The Requestor DN in the SWIFTNet Emission Profile is a valid licensed BIC. • The service does not mandate T-Copy or Y-Copy in its Application Service Profiles. At the start of every Direct FileAct message partner session, Alliance Access checks the associated FileAct service configuration, and stops the session if the service is configured for T-Copy or Y-Copy mode, or if the T-Copy or Y-Copy is mandatory for the Request Type. • The message partner session for the back-office application is enabled and open. 556 System Management Guide Appendix F - Connection Methods in AI Direct FileAct - Emission to SWIFTNet Alliance Access receives a file from a back-office application and sends it to SWIFTNet as follows: Direct FileAct - Emission to SWIFTNet Access Direct FileAct Adapter (From) FileActMessage Payload File 3 2 4 Filename.ext 1 SWIFTNet Interface Response File Transmission Notification Instance 5 6 Back Office Filename.ext <Ref> OK 7 8 Response File 9 TR_REC Direct FileAct Delivery Adapter (To) Notification Instance Delivery Notification (Optional) D0540188 Filename.ext <Ref> DL OK Emission of a file to SWIFTNet Alliance Access receives a file from a back-office application and sends it to SWIFTNet as follows: 1. The back-office application prepares a payload file and stores it in the data directory associated to a Direct FileAct message partner. This directory location is specified in the Direct FileAct Input Directory field. In this example, the file is named filename.ext. (See "Direct FileAct - Emission to SWIFTNet" on page 557). 2. The Direct FileAct input Message Partner (Application Interface) automatically detects the file and stores it in the database. Alliance Access automatically calculates the digest value of the payload file. The configuration parameter File Digest Algorithm specifies which Secure Hash Algorithm (SHA-1 or SHA-256) to use to calculate the digest value. 3. Creation of the FileAct message The Application Interface creates a FileAct-based message for sending over FileAct with the payload file. The File message contains a pointer to the payload file. The Direct FileAct message partner that is associated with the back-office application provides the following values for the FileAct message: • Requestor DN • Responder DN 15 July 2011 557 Alliance Access 7.0.20 • Service • Request Type • Priority The FileAct message is a message of type File, and is the original instance of the FileAct message. As with any other FileAct message, you can view the message in the Message File, print it, route it, and so on. Tip 4. You can view the message through the Configuration and Monitoring package on the Alliance Web Platform, but you cannot view the content of the payload file from the web platform. The SWIFTNet emission profile that is associated with the Requestor DN and the Service determines the FileAct transmission parameters: • Delivery Mode (real-time or store-and-forward) • Delivery Notification settings (with corresponding Responder DN, Request Type or Delivery Notification Queue) • Non Repudiation Required • Signing Required • Windows Size and Retry Limit Alliance Access routes the message according to routing schema that is defined for _SI_to_SWIFTNet, and the SWIFTNet Interface application transmits the file to SWIFTNet. 5. After the file is transferred successfully to the SWIFTNet Link (real-time mode) or to the store-and-forward queue of the back office's correspondent, the SWIFTNet Interface application generates a Transmission Notification Instance, which it routes to an exit point in the Application Interface. This instance is routed to a 'To' message partner that is associated with the back-office application and that does not use the Direct FileAct connection method. 6. The Direct FileAct adapter creates a response file with a file extension that indicates whether the file was transferred successfully to the correspondent. 7. Store-and-forward mode only: If the emission profile requested a delivery notification, then the following also occurs: a. The SWIFTNet Interface component receives the Delivery Notification message from SWIFTNet and routes it to the TR_REC module for reconciliation with the original message instance. (Step 7 in "Direct FileAct - Emission to SWIFTNet" on page 557) TR_REC processes the message and creates a Delivery Notification Instance for the original message. This instance is routed to a 'To' message partner that is associated with the back-office application and that does not use the Direct FileAct connection method. (Step 8 in "Direct FileAct - Emission to SWIFTNet" on page 557) b. In addition, the Direct FileAct adapter creates a response file with a file extension that indicates a successful delivery notification. (Step 9 in "Direct FileAct - Emission to SWIFTNet" on page 557) 558 System Management Guide Appendix F - Connection Methods in AI The response file is empty and the back office does not need to parse it. Only the extension of the file is relevant. For more information about Direct FileAct response files, see "Direct FileAct Transmission Status" on page 560. Tip F.1.4 Direct FileAct to the Back Office Before a file can be transmitted to Back Office The description of how Alliance Access handles the emission of a file from a back-office application to SWIFTNet assumes that: • A "To" message partner with the Direct FileAct connection method has been defined for the back-office application. An exit point is associated with this message partner. • The data directory where the back-office application will receive files from SWIFTNet has been defined and with correct access permissions. • The service does not mandate T-Copy or Y-Copy in its Application Service Profiles. At the start of every Direct FileAct message partner session, Alliance Access checks the associated FileAct service configuration, and stops the session if the service is configured for T-Copy or Y-Copy mode, or if the T-Copy or Y-Copy is mandatory for the Request Type. • The message partner session for the back-office application is enabled and open. Direct FileAct - Reception from SWIFTNet Alliance Access receives a file from SWIFTNet and sends it to a back-office application as follows: Direct FileAct - Reception from SWIFTNet Access 4 Filename*.SnRef SWIFTNet Interface 2 1 FileActMessage D0540190 Back Office Payload File Direct FileAct Adapter (To) 3 15 July 2011 559 Alliance Access 7.0.20 Reception of a file from SWIFTNet Alliance Access receives a file from SWIFTNet and sends it to a back-office application as follows: 1. The SWIFTNet Interface in Alliance Access receives a FileAct file-transfer notification from a SWIFTNet Reception profile. The delivery mode for the file transfer is either real-time or store-and-forward. SWIFTNet transfers the file in chunks to Alliance Access. 2. After Alliance Access receives the file successfully, it creates a message of type File, 'File MsgA-0', and routes the message instance to a 'To' Message partner that is associated with the back-office application and has a Direct FileAct connection method. The FileAct message, File MsgA-0', represents the original instance of the FileAct message. As with any other FileAct message, you can view the message in the Message File, print it, route it, and so on. 3. The Direct FileAct message partner generates a payload file, and stores it in the data directory Direct FileAct Output Directory, which is specified in the message partner. 4. The back-office application processes the payload file present in the data directory. Note No response files are created when files are being sent from SWIFTNet to a backoffice application. Payload filenames Alliance Access creates a unique filename for a payload file using the logical name of the incoming file from SWIFTNet and the SWIFTNet transfer reference. The FileAct logical names can contain only the characters A-Za-z0-9._. Alliance Access replaces other characters in the logical name of the incoming file with an underscore character, _. F.1.5 Direct FileAct Transmission Status Direct FileAct response file For every file that a back-office application sends to SWIFTNet, Alliance Access provides a response file to indicate the status to the file transfer. The Direct FileAct response file is an empty file of the same name as the original file and only the extension of the response file .<status> is relevant. The back-office application does not parse the response files, which makes it easy to integrate the back-office application with Alliance Access. The information returned by a response file is limited to the network status. It does not contain any additional information (such as detailed authentication information or reason for rejection or delivery notification). Alliance Access sends delivery notifications only in store-and-forward mode and if specifically requested in the Emission profile associated with the Requestor DN. In the following table, the original file that a back-office application sent to SWIFTNet is <filename.ext>. The name of the response file contains only the characters A-Za-z0-9._, and any other character in original filename is replaced by the _ character. Therefore, <filename.ext*>.<status> is the resulting file name. 560 System Management Guide Appendix F - Connection Methods in AI Transmission status The following table describes the transmission status of a file sent by Direct FileAct: .<status> Transmission Status TransferRef.ok TransferRef is the reference that SWIFTNet assigned to the initial FileAct Input message from the message partner to SWIFTNet. It is communicated to Alliance Access in the network acknowledgement. .ok indicates a positive network acknowledgement [TransferRef.]err TransferRef is the reference that SWIFTNet assigned to the initial FileAct Input message from the message partner to SWIFTNet. .err indicates that it was communicated to Alliance Access in a network negative acknowledgement (NAK). It is present only if the message was rejected after the point where SWIFTNet assigns a TransferRef. SnFRef.dlok SnFRef is the reference that SWIFTNet assigns to the initial FileAct Input message sent by the sender to SWIFTNet. .dlok indicates that the message was delivered successfully. SnFRef.dlnok SnFRef is the reference that SWIFTNet assigns to the initial FileAct Input message sent by the sender to SWIFTNet. .dlnok indicates that the message was not delivered. Examples You can view examples of some transmission statuses in the following sections: • "Direct FileAct from the Back Office" on page 556 • "Direct FileAct to the Back Office" on page 559 Enhanced transmission status If a back-office application can support more sophisticated integration logic, it is still possible to generate more detailed notification information. As shown in "Enhanced transmission status for Direct FileAct" on page 562, it is possible to create an additional copy of the transmission notification instance using the Routing application. To achieve this, you must define routing rules that send the notification copy to a message partner profile that uses the Transfer connection method to the back-office application. When the copy is routed to an exit point associated with the File Transfer message partner, then the Application Interface generates an XML version 2 based notification report that contains the details of the transmission notification. The same logic can be applied to network delivery notifications. 15 July 2011 561 Alliance Access 7.0.20 Enhanced transmission status for Direct FileAct Access Response File Transmission Notification Direct FileAct Instance Adapter (To) SWIFTNet Interface Filename.ext.err Back Office Notification Report File Output Adapter (To) Transmission Notification Instance (Copy) F.1.6 D0540189 XMLv2 Prepare to Use Direct FileAct Purpose Use the instructions in this section to prepare Alliance Access to communicate with a backoffice application using Direct FileAct. Directories for Direct FileAct The Direct FileAct adapter establishes an association between a set of directories and a FileAct correspondent. 562 System Management Guide Appendix F - Connection Methods in AI Access Payload Directory ... File MP 2 Back Office - Responder DN A - Service - ... - Responder DN B - Service - ... SWIFTNet Interface Directory ... MP 3 Correspondent A Correspondent B - Responder DN C - Service - ... Directory ... Direct FileAct Message Partners Correspondent C D0540185 MP 1 T-Copy and Y-Copy Direct FileAct does not support SWIFTNet T-Copy or Y-Copy services. Do not set up Direct FileAct for a service for which Y-Copy or T-Copy are defined as mandatory in their Application Service Profiles. Prepare to use Direct FileAct On Alliance Access, do the following: 1. Create the directories that Alliance Access will use for transferring files with each backoffice correspondent. Ensure that the directories have correct permissions: • Emission from Back Office It must be possible to open the Direct FileAct Input Directory. • Reception at the Back Office It must be possible to write to the Direct FileAct Output Directory. 15 July 2011 563 Alliance Access 7.0.20 2. Configure a message partner profile for each service and for each correspondent that the back-office application will communicate with. Note that: • Emission from Back Office For From Message Partners, the directory is specified in Direct FileAct Input Directory • Reception at the Back Office For To Message Partners, the directory is specified in Direct FileAct Output Directory field. The message partner profile will provide the FileAct transmission parameters for file transfers between the back-office application and the correspondent. 3. Use only valid and licensed BICs as values for Requestor DN. Validate that only Message Partner profiles that have the same Requestor DN use the same Direct FileAct Input Directory. 4. Verify the settings of the following system management parameters suit the requirements of the back-office application: • File Digest Algorithm 5. Transmission Notification and Delivery Notification message instances cannot be routed to a message partner with a Direct FileAct connection method. If the back-office application expects to receive them, then ensure that a message partner with a connection method that is not Direct FileAct is defined and enabled, to handle notification message instances. 6. F.2 Ensure that payload files do not exceed 250 MB. File Transfer Overview This section provides information about the File Transfer Connection method. This method differs from the Direct FileAct connection method because this method allows a back-office application to send files to several counterparties without specifying a message partner profile for each counterparty. For more information about Direct FileAct, see "Direct FileAct" on page 553. F.2.1 Transferring Files using the File Transfer Connection Method Overview The File Transfer connection method enables a back-office application to use Alliance Access to exchange files with SWIFTNet. The back-office application provides the transmission parameters for exchanging the file in an XML version 2 message, and in an optional parameter file. 564 System Management Guide Appendix F - Connection Methods in AI FileAct Settings Payload File + XMLv2 Any Data Back Office File Transfer Adapter Notification Report(s) D0540184 Alliance Access XMLv2 Alliance Access provides to the back-office application the notifications that are related to the file transfer. These notifications are reports in XML version 2, which the back-office application must parse to determine the exact transmission status. Alliance Access is not responsible for the physical exchange of messages with the message partner. A program known to Alliance Access as the Local Transfer Agent handles this task externally. Local Transfer Agent FTP FTP User Application D0540060 Alliance The File Transfer connection method supports automated batch input and output sessions. FileAct headers The payload of the XML version 2 message specifies the name of the original file to be transferred. It also specifies other elements to manage the transfer, and for some services, these elements may be mandatory. For example, a delivery notification may be mandatory for a particular service or Solution. The Application Service Profile defines the mandatory elements for a service. You can specify these key mandatory elements for a particular service in the FileAct header which allows the SWIFTNet central systems and the back-office applications that receive these messages to process these elements. For more information about specifying these elements, see the HeaderInfo element in "SWIFTNetNetworkInfo" on page 483. Data Formats for File Transfer Physically, the connection medium can be either a DOS formatted disk, or a system directory. The File Transfer connection method supports the optional use of parameter files to provide the processing information necessary to each communication session. 15 July 2011 565 Alliance Access 7.0.20 The following table lists the available data formats, connection points, and protocols that you can use with the File Transfer connection method: Data Format Connection Point Protocol DOS PCC (ST200 PCC) Directory Batch RJE (ST200 RJE) Directory Batch CAS 1/2 (NDF/NIF) Directory CAS Batch MERVA/2 Directory Batch XML version 1 or 2 Directory Batch Manual sessions When launching a manual File Transfer session, the operator must select the XML v2 file, not the payload file to be transferred. The Direct FileAct connection method allows you to select a payload file directly, to send to a counterparty. Tip Automated batch input and output sessions 1. Input from back-office application A back-office application stores the message file and parameter files in an input directory. Alliance Access scans the input directory periodically to detect the files. The way the operating system organises the directory structure determines the order in which files are processed. After Alliance Access detects a suitable file, it starts a communication session to exchange the file. Tip 2. If files are placed in the input directory at a faster rate than Alliance Access can poll and process them, then a problem may occur. You can avoid this by creating fewer files but each file can contain a larger number of messages and be sent at greater time intervals. Output to a back-office application For output sessions, the responsibility of Alliance Access ends when the parameter or message file is placed in the output directory. Alliance Access can launch the Local Transfer Agent automatically if specified. However, what the Local Transfer Agent does with the file lies outside the domain of Alliance Access because it is a user-defined utility. For more information, see: • "File Transfer Sessions Without Parameter Files" on page 567 • "File Transfer Sessions with Parameter Files" on page 568 566 System Management Guide Appendix F - Connection Methods in AI F.2.2 File Transfer Sessions Without Parameter Files Overview This section describes what happens during batch input sessions to Alliance Access and batch output sessions from Alliance Access when parameter files are not used. This section relates to the File Transfer connection method. What Happens During a Batch Input? From time to time, errors occur during the input of a batch file. To prepare for such events you can use the Batch File Validation button to determine whether the session must be aborted, or whether the session can continue (if the error is not a security issue) when these errors occur. When Continue on rejection is selected, and the message is flagged as modifiable, erroneous messages are passed to the MP_mod_text queue for manual recovery. If the message is flagged as non-modifiable, then the message is completed and a record is made in the Event Journal. When all messages in a batch input session are successfully processed, the session closes normally and the messages are routed. Manual Input Sessions For manual input sessions, the session is started using the Start Session command. The message file is read from the specified directory. From this file, the messages are processed one by one and placed on the AI inbound queue. These messages are held in a reserved state and the session stays open until all messages in the file have been processed. Automated Input Sessions The automatic initiation of input sessions is based upon a polling mechanism which scans the input directory for a suitable batch file. If the message partner is currently involved in a session, then the scanning process moves to the next connected message partner, and so on. The duty cycle of the polling mechanism is set using a configuration parameter called "Polling Timer" managed by the System Management application (SMA). For automated file transfer to take place, the software package 16:FILE AUTOMATED must be licensed on the system. For Alliance Workstation, all automatic sessions are run on the server machine. 15 July 2011 567 Alliance Access 7.0.20 What Happens During a Batch Output? Application Interface Message Partner Message Processing Function D0540062 Application Interface outbound When started, the batch output process for automated and manual sessions is basically the same in operation. It ensures that each message at the exit point is placed in a reserved state and then copied to an output message file. If all goes well then the messages are removed from the exit point when the file is successfully transferred to the disk. In normal operation, the session remains open and the messages in the exit point remain reserved until the file transfer has been completed. Note For the CAS 1 and 2 formats, messages are taken from any assigned exit points and are encoded according to the network format specified by the message partner profile. They are then sequentially appended to the message file. Regardless of how the output session was started, the session is closed when the file is transferred to the disk. If specified in the Message Partner Profile, then the Local Transfer Agent is invoked automatically and the user-defined script is run. F.2.3 File Transfer Sessions with Parameter Files Overview This section describes what happens during batch input sessions to Alliance Access and batch output sessions from Alliance Access when parameter files are used. This section relates to the File Transfer connection method. Manual Batch Input Session Using a Parameter File After a manual input session has been activated using the Start Session command, File Transfer checks the parameter file specified by the connection point to establish the location of the message data file. The message file is then read. A cyclic redundancy check (CRC) is made and the result stored in the batch history file. The result of the cyclic redundancy check is then checked against a pre-recorded value which was placed in the parameter file when the message file was created. If the check is correct then the session is started. The decoding is based on the format of the input message. This is established by either an auto-recognition process, or explicitly, depending on the setting for Format Recognition in the message partner profile. From this decoding process, Alliance messages are created and placed on the AI inbound queue. The stored result of the cyclic redundancy check is also used to check for file duplication. With manual input sessions, you are warned of file duplication errors. 568 System Management Guide Appendix F - Connection Methods in AI Automated Batch Input Session Using a Parameter File For automated input sessions started by the input polling mechanism, the Input path name field specifies the directory where parameter files can be found. The polling mechanism checks the directory specified in the Input path name field at regular intervals. If a file is present and no session is currently active, then the auto-start process starts an input session. The parameter file is scanned. From information present in this file, the identity of message partner is validated and the message data file is located and checked using the result of the cyclic redundancy check, just as described for manual sessions. If the cyclic redundancy check is successful then the session is started. Each message in the file is read and decoded by the MPF resident at AI inbound queue. The decoding is based on the format of the input message. This is established by either an auto-recognition process, or explicitly, depending upon the setting for Format Recognition in the message partner profile. From this decoding process, Alliance messages are created and placed on the AI inbound queue. Following a successful input session the messages are routed and the message and parameter file is moved into the FTAbackup directory. This directory is specified in the configuration parameter Batch Input - Automatic Input Backup Directory. Manual Batch Output Session Using a Parameter File Output sessions are invoked manually using the Start Session or Run Session command. First, the message partner profile is read to obtain the configuration details for the session, this includes the pathname of the parameter file. This pathname dictates where in the file system the message file (and automatically generated parameter file, in the case that no parameter file is specified), is placed after the batch session is complete. Messages are then taken from any assigned exit points and are encoded according to the network format specified in the message partner profile. They are then sequentially appended to the message file. When an output batch session is completed, a cyclic redundancy check is generated for the message file and the result is placed in the parameter file. For all output sessions, the Application Interface provides an interface whereby the Local Transfer Agent can be invoked though user-defined executables. These executables can be programs or scripts which handle the transfer of the parameter and message file (to the remote application) created by File Transfer. There is a "watchdog" configuration parameter called LTA_Timeout which is set in motion after the Local Transfer Agent command is run. If the Local Transfer Agent program has not finished its task at the end of the period set by this parameter, then an event is generated and placed in the Event Journal. When the Local Transfer Agent has finished its task an event is generated. This happens whether the Local Transfer Agent program was successful or not. Automated Batch Output Session Using a Parameter File Automated output sessions can be invoked in two ways: • By specifying an activation time in 5-minute slots (current date by default) • By specifying a common queue threshold for the message partner. When this threshold is reached the output session is started. For Alliance Workstation, all automatic sessions are run on the server machine. 15 July 2011 569 Alliance Access 7.0.20 For automated output sessions, the parameter file and message data file are generated automatically. When a session is started, messages are taken from any assigned exit points and are encoded according to the network format specified in the message partner profile. They are then sequentially appended to the message file. The messages are automatically appended with a three character extension specified by the user in the message partner profile. If no extension is given, then the extension .out is applied by default. When an output batch session is completed, a cyclic redundancy check is generated for the message file and the result is placed in the parameter file. The File Transfer application then calls the Local Transfer Agent program to start processing the parameter file and the encoded message file. For all output sessions, AI provides an interface whereby the Local Transfer Agent can be invoked by means of user-defined executables. The executables can be programs or scripts which handle the transfer of the parameter and message file (to the remote application) created by File Transfer. There is a "watchdog" configuration parameter called LTA_Timeout which is set in motion after the Local Transfer Agent command is run. If the Local Transfer Agent program has not finished its task at the end of the period set by this parameter, then an event is generated and placed in the Event Journal. This feature is activated by setting the configuration parameter LTA_waiting mode. When the Local Transfer Agent has finished its task an event is generated. This happens whether the Local Transfer Agent program was successful or not. F.2.4 Summary of Profile Settings Overview This section provides an overview of the options that you can set in a message partner profile for the File Transfer connection method. Note If you connect to a UNIX server When allowed session direction is set to To & From Message Partner and Input file format recognition is set to Forced, the Input and Output file format field are combined into a single button labelled Input & Output File Format. The restriction to the CAS2 input file format for automated format recognition remains the same. F.2.4.1 From Message Partner Profile settings 570 Session Initiation Parameter File Format Recognition Input Path Name Input File Formats Recognized Manual Not required Forced Specifies a pathname to an input message file DOS, RJE, MERVA/ 2, CAS1, CAS2 (ASN1, Text), XML Manual Required Forced Specifies a pathname to an input parameter file DOS, RJE, MERVA/ 2, CAS1, CAS2 (ASN1), Text, XML System Management Guide Appendix F - Connection Methods in AI Session Initiation Parameter File Format Recognition Input Path Name Input File Formats Recognized Manual Not required Auto-recognition Specifies a pathname to an input message file DOS, RJE, MERVA/ 2, CAS2* (ASN.1), XML Manual Required Auto-recognition Specifies a pathname to an input parameter file DOS, RJE, MERVA/ 2, CAS2* (ASN.1), XML Automatic Not required Forced Specifies a directory DOS, RJE, MERVA/ where input message files 2, CAS1, CAS2 may be found (ASN.1, Text), XML Automatic Required Forced Specifies a directory where input parameter files may be found Automatic Not required Auto-recognition Specifies a directory DOS, RJE, MERVA/ where input message files 2, CAS2* (ASN.1), may be found XML Automatic Required Auto-recognition Specifies a directory where input parameter files may be found Symbol * DOS, RJE, MERVA/ 2, CAS1, CAS2 (ASN.1, Text), XML DOS, RJE, MERVA/ 2, CAS2* (ASN.1), XML Explanation CAS1 protocol versions are only recognised when the Format Recognition is set to Forced F.2.4.2 To Message Partner Profile settings 15 July 2011 Session Initiation Parameter File Output Pathname Data Formats Available Output File Extension Manual Not required Specifies a pathname where the output message file is placed DOS, RJE, MERVA/2, CAS1, CAS2 (ASN1, Text), XML Not required. File pattern in the Output path name is used. Manual Required Specifies a pathname to where the message file and parameter file is placed. If the parameter file is not named explicitly, then it is automatically generated with a proprietary format. DOS, RJE, MERVA/2, CAS1, CAS2 (ASN1, Text), XML Not required. The message file takes the file extension, .out, automatically Automatic Required Specifies the directory where the automatically generated parameter and message files are placed DOS, RJE, MERVA/2, CAS1, CAS2 (ASN1, Text), XML Specify the extension of the message file. If not specified, then the default extension .out is taken. Any pattern specified in the Output path name is ignored. 571 Alliance Access 7.0.20 F.2.5 Session Initiation Parameter File Output Pathname Data Formats Available Output File Extension Automatic Not required Specifies a directory where the generated message file is placed DOS, RJE, MERVA/2, CAS1, CAS2 (ASN1, Text), XML Specify the extension of the message file. If not specified, then the default extension .out is taken. Any pattern specified in the Output path name is ignored. Checking for Message File Duplication On input message files The result of the Cyclic Redundancy Check on each input message file received by Alliance Access is kept in a batch history file. The Cyclic Redundancy Check value is the result of a mathematical function applied to the sum of the file contents and, with the file name, uniquely identifies the file to the input session. Each time the system processes an incoming message file, a check is made between the Cyclic Redundancy Check of the message file and the batch history file. If a match is found, then the system alerts the operator of a possible duplication, thus preventing processing and routing the same set of messages more than once. If a match in the Cyclic Redundancy Check of a batch file is found, then a prompt is issued: "This batch file has already been used. Do you want to re-use it?" If the operator decides to proceed with the session in spite of a duplication warning, then a Possible Duplicate Emission is added automatically. In addition to a record of Cyclic Redundancy Check calculations, the system also keeps a record of message file names. If no Cyclic Redundancy Check match is found, then a secondary check on used message file names is carried out. If a match on file name is found, then the same warning prompt "This batch file has already been used. Do you want to re-use it?" is issued. The length of time that a record is kept of message file names is set by the configuration parameter Batch Input - History Period. For more information about this configuration parameter, see "Batch Input " on page 161. On output message files For output message files, a check is made to see whether the message file exists on the target directory. If a match on file name is found, then the warning prompt "File <filename> already exists, do you want to overwrite" is issued. If the operator decides to proceed with the session in spite of a duplication warning, then any matching file in the target directory is overwritten. 572 System Management Guide Appendix F - Connection Methods in AI F.2.6 Recovery of Batch Sessions Batch output The batch output process for File Transfer ensures that each message is written from the exit point to disk by means of an intermediate file. If anything goes wrong with the session, then the recovery mechanism unreserves and requeues the messages at the exit point. An event concerning the session failure is recorded in the Event Journal. It is the same process for File Transfer when using any of the other message formats, except that no intermediate file is required. Batch input With batch input sessions, the session operation and recovery principle is very similar. If anything goes wrong with the session, then the recovery mechanism unreserves, removes, and discards the messages in the AI inbound queue. Automatic sessions If an error occurs, then the batch input message file is moved into a storage location known as the Automatic Input Error Directory (set by the system parameter Automatic - Error Dir). If a parameter file is being used, then the parameter file is moved into this Error Directory. If the message file and parameter file are located in the same connection point directory, then both are moved into the Error Directory. To avoid filename clashes, each file placed in the Error Directory is given a file extension YYMMDDHHMMSS. An event concerning the reason for the session failure is recorded in the Event Journal. F.3 Interactive Overview The Interactive connection method is used to transfer messages of a specified format between Alliance Access and a message partner. This transfer is carried out according to Common Application Server (CAS) standards. For more information about CAS, see "CAS Protocol" on page 574. The Interactive connection method permits message transfer in the following directions: • To message partner • From message partner • To and from message partner Depending upon a setting of the message partner profile, permission to start a session can be granted specifically to Alliance Access or to the message partner, or to both parties. Sessions can be stopped or aborted at any time by either party. 15 July 2011 573 Alliance Access 7.0.20 Protocol for Interactive connection method The protocol for the Interactive connection method currently supported in Alliance Access is: • TCP/IP: Transmission Control Protocol/Internet Protocol F.3.1 CAS Protocol Overview As part of the Application Interface (AI), Alliance Access supports CAS protocol standards 1 and 2. Both these CAS protocols provide a common form of access between SWIFT terminal products (CBTs) and back-office mainframe applications. In addition, use of the CAS protocol permits Alliance Access to store messages that it receives from networks other than SWIFT. Therefore, messages that use protocols other than SWIFT can be processed and "switched" through Alliance Access like calls through a telephone exchange. CAS protocol The Common Communication Interface (CCI) together with the channel handler and protocol units, are known as the CAS communications stack. Together they are responsible for providing transparent and reliable communications between AI and a message partner. The channel handler is responsible for taking messages received from the network protocols by means of the CCI, and delivering them one at a time (in the correct format) to AI. It also provides a service in the reverse direction, that is, taking messages from AI and presenting them one at a time to the CCI. The CCI is a software module which provides a "common transport interface". This interface handles messages to and from the underlying communication protocols. The communication protocols are the software programs which carry the messages across the network. Alliance & Application Interface Channel Handler Common Communication Interface TCP/IP Common Application Server communications stack TCP/IP Message Partner & User Application D0540066 Access A relevant message partner profile defines which protocol is used for a communication session using CAS. 574 System Management Guide Appendix F - Connection Methods in AI Message format Alliance Access accepts a message that is transmitted using the CAS protocol if it has one of the following formats: • Network Dependent Format (NDF) This format matches the SWIFT network. Using the NDF format, financial institutions currently communicating with ST400 systems can re-use much of their CAS application software when switching to Alliance Access. • Network Independent Format (NIF) With NIF, the body of the message is limited to the financial data, that is, block 4 of the SWIFT message format, while the network-related information is in a network independent format. Using the NIF syntax permits financial institutions to use Alliance Access to exchange and process messages which are coming from SWIFT or non-SWIFT networks, for example, CHIPS, CHAPS, Fedwire, SIC, and so on. Network Format NDF NIF SWIFT Message Syntax Table Message Syntax Table UNIX only: Sic - UFS (User Format Services) UNIX only: Other networks - UFS Message encoding and decoding The NDF/NIF formats are defined using the ISO standard Abstract Syntax Notation 1 (ASN.1). Its companion the Basic Encoding Rules (BER) Standard defines how data described using ASN.1 can be exchanged using a common transfer syntax. The messages exchanged between Alliance Access and message partners are encoded to the common transfer syntax for transmission, and from the common transfer syntax on reception. In addition to the ASN.1 notation used by both CAS 1 and CAS 2 standards, the CAS 2 standard also supports a notation called Text Encoding. This notation has been developed to simplify the implementation of the CAS protocol. The structure and parameters of the CAS protocol remain unchanged, but the text encoding method uses special text characters to delimit the start and end of each structure block and field within the message. 15 July 2011 575 Alliance Access 7.0.20 F.3.2 What Happens During an Interactive Session? Overview For Interactive communications, there are three important transmission modules within the Application Interface: Control, Send, and Receive. These modules handle messages that are sent to and from the CAS communications stack. Operator commands e.g., 'Run session' Message Exchange Services User Interface Control Send Receive D0540067 Common Application Server Communications Stack To/From message partners • Send: assembles the message and passes the message to the channel handler. • Receive: validates and routes the received message. The Receive module is also responsible for sending logical replies to the message partner. • Control: is responsible for interaction with the operator by means of the GUI, and for the following operations: – for opening and closing the session – listening to the line after a message partner is enabled – managing a session abort. Send Messages During an interactive session with a message partner, messages are sent one at a time by the Send module to the message partner through the CAS communications stack. A logical reply is relayed to the sender, and another message can then be sent to the message partner. If the message exchange session is using a messaging window value of greater than 1, then the message partner can transmit this number of messages before having to wait for a reply. 576 System Management Guide Appendix F - Connection Methods in AI If the session was started with the Start Session command, then the session remains open and messages arriving at the exit point(s) are queued and transmitted straight away. The session stays open until: • either Alliance Access or the message partner issues the Stop Session command • the session fails • either Alliance Access or the message partner aborts the session. If the session was started with the Run Session command (to message partner only), the session remains open until: • all messages present in the exit points at run time have been sent to the message partner • either Alliance Access or the message partner issues the Stop Session command • the session fails • either Alliance Access or the message partner aborts the session. Receive Messages During an interactive session with a message partner, messages are received one at a time by the Receive module through the CAS communications stack. As the Receive module receives each message, a validation and a local authentication check can be made. If the message passes the required validation level, then Base Services accepts the message, and a positive reply is generated and sent to the message partner by the Receive module. The message partner can then send another message. If the message fails the required validation level then it is rejected with a negative reply and a record of the event is written in the Event Journal. The message is either routed to _MP_mod_text or completed, depending on the parameter "Message Modification Allowed Yes/No''. If the message fails the local authentication check, then the session is aborted. The session is started with the Start Session command and remains open until: • either Alliance Access or the message partner issues the Stop Session command • the session fails • either Alliance Access or the message partner aborts the session. The session is terminated using the Stop Session command. Note F.3.3 During an interactive session, flow in either direction may be handled. How are Interactive Sessions Handled? Overview Interactive sessions are opened, closed, and aborted by means of requests from either the Alliance Access operator or the back-office application. Example (for an Interactive Messaging Window Size = 1) Take for example an Alliance Access operator issuing the Run Session command. In this example, two messages are sent to the message partner. The operator selects the Run Session command and Alliance Access sends an event "Run Session" to the Control module. The Control module reads the message partner details from the 15 July 2011 577 Alliance Access 7.0.20 Message Exchange Services (MXS) and then sends an event to the channel handler. The channel handler then attempts to open a session with the equivalent message partner session layer by communicating an OpenRequest. If the message partner recognises the request, then it responds with an OpenConfirm. The session is now open. When the session is open, the Send module examines all exit points assigned to the message partner and begins transmitting the first queued message to the message partner (DATA1). Upon receipt of a positive reply (Reply1), the next message can be sent (DATA2). When the last reply (Reply2) has been received, the channel handler issues a TermRequest across the connection to close the session. The message partner responds with a TermConfirm and the session is closed. Alliance OpenRequest Message Partner OpenConfirm DATA1 Reply1 Window size 1 DATA2 Reply2 TermRequest D0540068 TermConfirm Interactive Messaging Window Size By setting the field Window Size, the sender can transmit a set number of messages before receiving a reply. For example, if the window size is set to 5, then five messages may be sent sequentially to the receiver before a reply on the first message is required (if the operator opened the session). The requested window size is given by the initiating message partner in the OpenRequest SPDU. The corresponding message partner confirms the window size (or a lower value in some cases) within the OpenConfirm SPDU. Logical replies are relayed to the sender in the same sequence that they are received. Recovery Mechanisms For a description of the recovery mechanisms used by the Interactive method in case of failure, see "Interactive Sessions" on page 579. If a session is aborted when a window size of more than 1 is implemented, then the receiver must discard any messages that the sender sent but which the receiver has not processed. This applies directly to messages which have not yet received a logical reply. 578 System Management Guide Appendix F - Connection Methods in AI Message validation and disposition For information about the disposition of CAS messages after arriving in Alliance Access, see Appendix E, "Message Validation and Disposition" on page 543. This section addresses various fields present in the Data APDU, and the entitlements that the message partner permission profile possesses. F.3.4 Interactive Sessions Description Session recovery for interactive sessions involves restarting the session using the same session number as the failed session. Session recovery begins by transmitting an OpenRequest SPDU. Either party can send the SPDU and it contains: • The sequence number (incremented by one) of its last fully transmitted and acknowledged message • The session number used for the recovered session. This is always the sequence number of the failed session • A software flag recoveryIndication = TRUE indicating that this is a recovery request. The other side replies with an OpenConfirm SPDU. This SPDU includes the input sequence number (incremented by one), of its last fully transmitted and acknowledged message from that side. Scenario During the transmission of a message to a message partner, the session is aborted before Alliance Access receives the logical reply. After the session is closed, the operator moves the message to a different exit point. Then, Alliance Access re-opens the session. In such cases, Alliance Access sends the message to the message partner even though the exit point to which the message has been "moved" is no longer assigned to the message partner. Note for UNIX: connection problems arising when using TCP/IP protocol The following error messages appear when a TCP/IP error occurs. Exactly which message depends on which of the following files is out of configuration: • protocol file • services file • hosts file problem in protocols file: Message Partner <message partner name> - TCP connection error Reason: Could not obtain protocol number for protocol name TCP. Failed to initiate communication. problem in services file: Message Partner <message partner name> - TCP connection error Reason : Unable to find service name MPconn... Failed to initiate communication. problem in hosts file : Message Partner <message partner name> 15 July 2011 579 Alliance Access 7.0.20 - TCP connection error Reason : Unable to get host information for host name <host name> Failed to initiate communication. To get the relevant information about the error message, look into the Event Journal for the event. TCP_connection error reason: description of the problem. reason can be : -Could not obtain protocol number from protocol name: protocol name -Unable to find service name : service name -Unable to get host information for host name : hostname. In all cases, use the help of the UNIX system administrator to resolve the problem. F.4 Print Overview This section provides information about the Print connection method that you can use to print messages in batch to a printer or file. F.4.1 Description of the Print Connection Method Overview The Print connection method permits the output of messages in batch to a specified printer or to a file in a user specified directory. For Alliance Workstation, the field labelled Printer Hostname can be used to select the name of the machine where the required printer is connected. The definition of the paper size, font, font size, margins, and, optionally, paper orientation, for the selected printer can be made from the Application Interface application. Additionally, to save paper usage, notifications can be printed to the output device without including interventions. Output messages can also be printed in ST200-like format, which can also include warning indications, or eye-catchers, in the header of the output. For information about the format of the message report after the messages are printed, see "Printed Message Reports" on page 581. Print Sessions A print session can only have one allowed direction, To Message Partner. An operator can start a print session either automatically or manually using the Start Session or Run Session command. Messages are not printed until the operator stops the session because the printer spool job is not actually queued until the print session is closed. On UNIX only: to recover from problems incurred during a Print session, for example, a paper jam, toner low, and so on, the system administrator may be required to resubmit the spool job manually. 580 System Management Guide Appendix F - Connection Methods in AI F.4.2 Manual Print Sessions Overview A manual print session is started using either the Run Session or Start Session commands. When a Print session is started using the Run Session command, then the session is automatically stopped only when all the messages queued at assigned exit points have been processed. When the Print session is started using the Start Session command, then the operator stops the session using the Stop Session command. F.4.3 Automated Print Sessions Overview Automated print sessions may be triggered from one of two sources: • When a specified number of messages are present at the assigned output queue(s). • A scheduled print time arrives. The session closes when all messages have been processed. F.4.4 Printed Message Reports Introduction Printed message reports are generated when a message is routed to a Print message partner, or when messages are printed on demand. Messages are printed on demand by selecting the Message Partner Print Layout option in Alliance Workstation or by selecting the Print Instance option in Alliance Messenger (available on Alliance Web Platform). Report content The report for a message instance consists of the following sections: • Warning header • Transmission section • Message Header section • Message Text section • Message Trailer section • Intervention section Each message starts on a new page. The page header includes date and time information, as well as the name of the message partner and its session and sequence number. The report indicates that the information is a reprint and thus the values for session and sequence number are all zero. The configuration parameters of the classes Print and Display/Print influence the content of the printed report. For more information, see "Classes of Configuration Parameters" on page 159. 15 July 2011 581 Alliance Access 7.0.20 Eye-catcher Text When printing in ST200-like format, a warning identification, which is called eye-catcher text, indicates an exceptional condition. Note Eye-catchers are not printed when the option for printing to a file is used. The eye-catcher codes in the following table are shown in order of preference. This means that if more than one condition applies, then only the eye-catcher that is related to the first condition is printed: Eye-catcher Text Condition NAK NAK'd message. Message is an input message, the delivery status is Not Acknowledged (NAK). SAI Authentication and/ or authorisation incorrect. Message is an output message, the message authentication and/or authorisation verification failed. SAB Authentication and/ or authorisation bypassed. Message is an output message, the authentication and/or authorisation were bypassed. FAI FINCopy Authentication incorrect. Message is a FINCopy output message, the FINCopy authentication verification failed. FAB FINCopy Authentication bypassed. Message is a FINCopy output message, the FINCopy authentication code verification was bypassed. FAN FINCopy Authentication missing. Message is a FINCopy output message, the FINCopy authentication is not present. RTV Retrieved message. Message is an input or output message that has been retrieved. *** Original Message is an output message received from the SWIFT network and the instance is an original. Note: This means that only 1 instance contains the *** eye-catcher. Warning headers - Alliance format The default warning header is the Alliance format. If Sanctions Screening over SWIFT flags a message as a true hit, then the Warning Header includes the warning, Sanctions screening - Message blocked. For more information about true hits, see "Configuration for Sanctions Screening over SWIFT" on page 300. With this format, the warning header indicates that a message is a possible duplicate under any of the following conditions: • The message was sent to the network with a Possible Duplicate Emission trailer • The message was received with a Possible Duplicate Emission or Possible Duplicate Message trailer • The message instance is a notification and an emission appendix exists before the related appendix If a previous transmission attempt was made, then the warning header includes transmissionrelated details for the network, session holder, session number, sequence number, and delivery status. 582 System Management Guide Appendix F - Connection Methods in AI Brief information prints in case authentication was successful or was not applicable for the message. If the message being printed is a retrieved MT message, then the text prints accordingly. Warning headers - ST200-like format If Sanctions Screening over SWIFT flags a message as a true hit, then the Warning Header includes the warning, Sanctions screening - Message blocked. For more information about true hits, see "Configuration for Sanctions Screening over SWIFT" on page 300. Text Description *** Nacked Message *** Prints only for an input message. Appears if the network delivery status of the related appendix indicates that the message was not acknowledged (NAK). *** Authentication Result: <value> *** The following values are possible for the authentication result message, based on whether the message is MT or MX, and depending on the related appendix: • Correct with current key • Incorrect • Correct with old key • Correct with future key • Authentication bypassed *** Authentication/Authorisation Result: value> *** Printed only for an output MT message. The following value is possible: • Incorrect *** Authorisation Result: <value> *** Printed only for a message that requires authorisation. The following values are possible: • No Record • Not Enabled • Invalid Period • Unauthorised *** Authorisation key not present *** Prints only for an output MT message that requires authorisation. Printed if no authorisation key is available. *** FIN-Copy Authentication Result: <value> *** Prints only for an output MT message that requires proprietary authentication. The following values are possible for an MT message, based on the related appendix: • Correct with current key • Incorrect 15 July 2011 583 Alliance Access 7.0.20 Text Description • Correct with old key • Correct with future key • Authentication bypassed • Proprietary Authentication Code trailer missing *** FIN-Copy Authentication/Authorisation Result: <value> *** Prints only for an output MT message that requires proprietary authentication. The following values are possible for an MT message, based on the related appendix. The following value is possible: • Incorrect *** Possible Duplicate Emission *** Prints if the message is sent to the network with a Possible Duplicate Emission trailer, or if the message instance is a notification and an emission appendix exists before the related appendix. *** Possible Duplicate Reception *** Prints if the message is received from the network with a possible duplicate emission or Possible Duplicate Message trailer. *** Test and Training Mode *** Prints if the MT message sent or received is from/to a Test & Training destination. If a previous transmission attempt was made, the warning header includes transmission-related details for the network, session holder, session number, sequence number, and delivery status. Instance type and transmission The content of this section of the report varies, depending on the instance type and the type of transmission. The report always shows the network used to send the emission or reception appendix for a message. The following table explains additional content that can appear in the Instance Type and Transmission section: Instance type / transmission Content Notification / emission Indicates the notification type, and includes the type of the related instance. Network acknowledgement information is printed. For notification type "Transmission", the report includes Network Delivery Status: <value>. For notification type "Delivery", the report includes User Delivery Status: <value>, possibly followed by NAK information. If the instance is for an MT message that is not an APC message, then the report includes Priority/Delivery : <value>. This information indicates the priority (System, Urgent, or Normal) and can be followed by the delivery status (Non-Deliv Warning or Deliv Notif). The message input reference prints in this part of the report. Notification / reception Indicates the notification type, and includes the type of the related instance. If the instance is for an MT message that is not an APC message, then the report includes Priority: <value>. The message output reference prints in this part of the report, along with the correspondent input reference. 584 System Management Guide Appendix F - Connection Methods in AI Instance type / transmission Content Original or Copy / emission Indicates the instance type and whether there is a related instance, and shows network acknowledgement information. If the instance is not for a FIN system message, then the report includes Priority/ Delivery : <value>. This information indicates the priority (System, Urgent, or Normal) and can be followed by the delivery status (NonDeliv Warning or Deliv Notif). The message input reference prints in this part of the report. Original or Copy / reception Indicates the instance type and whether there is a related instance. If the instance is for an MT message that is not an APC message, then the report includes Priority: <value>. The message output reference prints in this part of the report, along with the correspondent input reference. Message header The content of this section of the report is relevant to the message itself, and not specific to the particular instance that has been printed. Some content is common for both MT and MX messages: • Message format • Message direction (input or output) • Transmission network • Message type and message name Details from the Correspondent Information File print for sender and receiver (MT message) or for the BIC8 that is part of the Requestor DN and Responder DN (MX message). The following additional information prints for an MT message, if present: • Message User Reference • Banking Priority • Server to Receiver Instructions • FINCopy service • Textblock Authentication, which includes User Code and MAC Result For an MX message, the following information is included in the report: • User Reference • Service Name • Non-repudiation Indicator • Non-repudiation Type • Non-repudiation Warning • SWIFT reference • SWIFT Request Reference • CBT Reference 15 July 2011 585 Alliance Access 7.0.20 • Store-and-forward Input Time (if relevant) • Signing DN FIN User Header The printed report contains the section, FIN User Header, in the following conditions: a. The value of the Display/Print - FIN User Header configuration parameter is set to Yes, and b. The message instance is printed through a Print message partner Message text The text of the message prints for any fields that contain values. The FIN User Header (Block 3) is printed in the following conditions: a. The value of the Display/Print - FIN User Header configuration parameter is set to Yes, and b. The message instance is not printed through a Print message partner Message trailer The message trailer of an MT message prints after the message text. Interventions The interventions print for an instance if the Print - Skip Interventions parameter is set to No. For an MX message sent using real-time delivery, intervention details of a Transmission Response (containing the Business Response) are preceded by the following information: • SWIFT Reference • Responder Reference • Signing DN • Signature Result • Non-repudiation Type • Non-repudiation Warning • CBT-Reference • Possible Duplicate Indication • Responder DN End of message trailer When printing reports in ST200-like format, each message is terminated by an end-of message trailer: *End of Message Note 586 The end-of-message identifier is not printed when using the option for printing to a file on Alliance Workstation. System Management Guide Appendix F - Connection Methods in AI F.5 SOAP Introduction This section provides information about the SOAP connection method that you can use to transfer MT, XML-based, or FileAct messages between Alliance Access and a back-office application. F.5.1 SOAP Host Adapter Overview The SOAP connection method enables the exchange of MT, XML-based, or FileAct messages between Alliance Access and back-office applications through the SOAP protocol. The SOAP connection method requires the licence package 14:SOAP ADAPTER and supports the XML version 2 data format of revision 2 or higher. The SOAP message carries the XMLv2 message. The parameters that control the file transfer include a pointer to the payload file, service, receiver of the file, header information, and notification options. These file-transmission parameters are carried in an XMLv2 message. Note It is always the back-office application that starts a SOAP session with Alliance Access. FileAct over SOAP The SOAP Host Adapter supports the exchange of FileAct messages over HTTPS in two modes: • Full FileAct mode, where file transmission parameters and the FileAct payload are transferred in XMLv2 format and the data exchange uses Web services over HTTPS. • Mixed FileAct mode, where the file transmission parameters are carried in an XML version 2 message that is transferred using Web services over HTTPS, whereas the FileAct payload is transferred over the local file system. SWIFT-defined SOAP Protocol Alliance Access controls the interactive exchange of SOAP messages between the back-office applications and Alliance Access using an additional SWIFT-defined protocol on top of the SOAP protocol. This protocol provides a set of primitives to manage the message exchange sessions, to guarantee and ensure unique delivery of messages. SOAP Primitives The following SOAP primitives are used in SOAP messages: • Open: open a session • Close: close a session • Put: send a message to Alliance Access • GetAck: request Alliance Access to send a message that is waiting delivery to the backoffice application, and optionally, acknowledge a message received from Alliance Access • Ack: acknowledge a message received from Alliance Access 15 July 2011 587 Alliance Access 7.0.20 These primitives are implemented as operations of the SOAP host adapter Web service, which is described in "SOAP Host Adapter Web Service" on page 608. In this context, the request and response messages are SOAP messages exchanged over HTTPS. For more information about the structure of SOAP messages, see "SOAP Message" on page 601. Error Handling When errors are encountered between the back-office applications and the SOAP host adapter, the standard SOAP fault error mechanism is used. When such SOAP fault errors are generated, the back-office can retry the requests except where the error refers to a session error (invalid token). For more information, see "Recovery of a SOAP Session" on page 595. F.5.2 SOAP Message Flow from Back-office Application Types of information emitted to SWIFTNet A back-office application can send the following information to Alliance Access in XMLv2 data format over SOAP: 1. MT message 2. XML-based message 3. A file (FileAct) Before a message can be transmitted to SWIFTNet The description of the message flow assumes that: • A From or To&From message partner that uses the SOAP connection method. • For mixed FileAct mode: The data directory that corresponds to the Input Attachment Directory in the message partner profile has been defined and with correct access permissions. The back-office application will store files for sending to SWIFTNet in this directory. 588 System Management Guide Appendix F - Connection Methods in AI SOAP - emission to SWIFTNet Alliance Access receives an MT, XML-based, or FileAct message from a back-office application over SOAP and sends it to SWIFTNet as follows: Alliance Access Application Server Back Office Open SOAP OpenResponse SOAP Session Token Put XMLv2 Message Several Put requests SOAP PutResponse SOAP XMLv2 MessageStatus Close SOAP CloseResponse SOAP D0540141 XMLv2 SessionStatus The back-office application can send Put request to Alliance Access if the SOAP message partner that is defined in Application Interface allows it. It can send several Put requests during one session. Note 15 July 2011 If the message partner is defined as To&From message partner, then messages are exchanged using the Put and GetAck messages while the session is open. 589 Alliance Access 7.0.20 Emission of a file to SWIFTNet Alliance Access receives a file from a back-office application and sends it to SWIFTNet as follows: 1. The back-office application prepares the SOAP message that contains the MT, MX, or FileAct message: FileAct mode Action taken by back-office application Full Adds the payload file as a SOAP attachment to the XML message, and optionally, signs the attachment. The body of the XML message is not required. Mixed Stores any payload files in the data directory that corresponds to the Input attachment directory in the SOAP message partner profile. Places the name of the payload file in the body of the XML message. 2. The back-office application starts a session by sending an Open request. Alliance Access confirms the session is open by sending an OpenResponse. This response contains the session token that identifies the session, and which must be used in each message that is exchanged as part of the session. 3. The back-office application sends a Put request, which has the XMLv2 message as its payload. This XMLv2 message contains the details of an MT, XML-based, or FileAct message. 4. On reception of the Put request, Alliance Access performs the following actions: a. Validates the session token in the Put message, to ensure that it matches the token returned in the OpenResponse. b. If the SOAP message partner that is associated with the session is configured for local authentication, then Alliance Access checks the local authentication of the message. For more information, see "Local Authentication of SOAP Messages" on page 602. c. Checks that the sequence number of the received message is within the window size is defined for the session. For more information about how the sliding window works in the SOAP host adapter, see "Window Size" on page 596. d. Processes the payload of the Put message, which contains the MT, XML-based or FileAct message. It may store the MT or XML-based message in the Alliance Access database. For FileAct messages, the processing of the SOAP message varies depending on the FileAct mode, as follows: FileAct mode Full 590 Actions Alliance Access checks that the XML message has a SOAP attachment that contains a payload file. If the SOAP attachment is signed, then Alliance Access also checks that the signature is correct. System Management Guide Appendix F - Connection Methods in AI FileAct mode Mixed 5. Actions Alliance Access extracts the name of the payload file from the body of the XML message. Then, it checks that a file with that physical name exists in the Input Attachment Directory, and has the permissions to be read and moved after processing. For FileAct messages, Alliance Access automatically calculates the digest value of the payload file, and stores the file in the database. The configuration parameter File Digest Algorithm specifies which Secure Hash Algorithm (SHA-1 or SHA-256) to use to calculate the digest value. 6. If the processing of the Put message is successful, then Alliance Access replies to the back-office application with a PutResponse. If not, a SOAP fault message is sent to the back-office application. For more information about SOAP faults, see "SOAP Fault - soapenv:Fault" on page 607. The session remains open, and Alliance Access processes subsequent Put messages based on the window size. 7. The back-office application ends an interactive SOAP message exchange session with Alliance Access by sending a Close message that specifies the session token of the session to be closed. Alliance Access sends a CloseResponse message to confirm that the session is closed. Payload filenames The file name can contain the characters, A-Za-z0-9._. Alliance Access replaces any other character with an underscore _. Depending on the value of the Extension field in the message partner profile, an optional file name extension is added to the file name. F.5.3 SOAP Message Flow to Back-office Application Types of information received from SWIFTNet Alliance Access can send the following information to a back-office application in XMLv2 data format over SOAP: 1. Transmission Notification 2. Delivery Notification 3. History Notification or Information Notification 4. A file (FileAct) 15 July 2011 591 Alliance Access 7.0.20 Before a message can be received from SWIFTNet The description of the message flow assumes that: • A To or To&From message partner that uses the SOAP connection method. • For mixed FileAct mode: The data directory that corresponds to the Output Attachment Directory in the message partner profile has been defined and with correct access permissions. The back-office application searches this directory for files that it receives from SWIFTNet. • An Exit point is defined for the message partner, to hold the messages that are awaiting delivery to the back-office application. SOAP - reception from SWIFTNet Alliance Access Application Server Back Office Open SOAP OpenResponse SOAP Session Token GetAck SOAP Several GetAck requests GetAckResponse SOAP XMLv2 Message Close SOAP CloseResponse SOAP D0540142 XMLv2 SessionStatus 592 System Management Guide Appendix F - Connection Methods in AI The back-office application can send GetAck request to Alliance Access if the SOAP message partner that is defined in Application Interface allows it. It can send several GetAck requests during one session. Note If the message partner is defined as To&From message partner, then messages are exchanged using the Put and GetAck messages while the session is open. Reception of a file from SWIFTNet Alliance Access receives a file from SWIFTNet and sends it to a back-office application, as follows: 1. The back-office application starts a session by sending an Open request. Alliance Access confirms the session is open by sending an OpenResponse. This response contains the session token that identifies the session, and which must be used in each message that is exchanged as part of the session. 2. The back-office application sends a GetAck request, to retrieve any messages that are waiting to be delivered to the back-office application. The GetAck request has a timeout specified in it. 3. On reception of the GetAck message, Alliance Access performs the following actions: a. Validates the session token in the GetAck message, to ensure that it matches the token returned in the OpenResponse. b. If the SOAP message partner that is associated with the session is configured for local authentication, then Alliance Access checks the local authentication of the message. For more information, see "Local Authentication of SOAP Messages" on page 602. c. Checks that the sequence number of the received message is within the window size is defined for the session. For more information about how the sliding window works in the SOAP host adapter, see "Window Size" on page 596. d. If the GetAck request specifies an Ack client reference, then Alliance Access marks the associated message as acknowledged. e. Fetches the next MT or XML-based message that is waiting for delivery in the exit point. For FileAct, Alliance Access prepares the SOAP message to transfer the file: FileAct mode 4. 15 July 2011 Action taken by Alliance Access Full Adds the payload file as a SOAP attachment to the XML message. The body of the XML message is not required. Mixed Stores the payload file in the data directory that corresponds to the Output attachment directory in the SOAP message partner profile. Places the name of the payload file in the body of the XMLv2 message. If the processing of the GetAck message is successful, then Alliance Access replies to the back-office application with a GetAckResponse. If not, a SOAP fault message is sent to the back-office application. 593 Alliance Access 7.0.20 For more information about SOAP faults, see "SOAP Fault - soapenv:Fault" on page 607. The session remains open, and Alliance Access processes subsequent GetAck messages based on the window size. 5. The back-office application ends an interactive SOAP message exchange session with Alliance Access by sending a Close message that specifies the session token of the session to be closed. Alliance Access sends a CloseResponse message to confirm that the session is closed. Payload filenames The file name can contain the characters, A-Za-z0-9._. Alliance Access replaces any other character with an underscore _. Depending on the value of the Extension field in the message partner profile, an optional file name extension is added to the file name. F.5.4 Prepare to Use FileAct over SOAP Purpose Use the instructions in this section to prepare Alliance Access to communicate with a backoffice application using SOAP. Prepare to use FileAct over SOAP On Alliance Access, do the following: 1. Determine which FileAct mode to use: • full Next, go to Step page 595. • mixed Next, go to Step page 594. 2. Create the directories that Alliance Access will use to exchange files with each back-office application. Ensure that the directories have correct permissions: • Emission from Back Office It must be possible to open the Input Attachment Directory. • Reception at the Back Office It must be possible to write to the Output Attachment Directory. 594 System Management Guide Appendix F - Connection Methods in AI 3. Configure a message partner profile for each back-office application that will use SOAP to communicate with Alliance Access. Note that: • Emission from Back Office From Message Partners: the directory is specified in Input Attachment Directory • Reception at the Back Office To Message Partners: the directory is specified in Output Attachment Directory field. The message partner profile will provide the SOAP transmission parameter for file transfers between the back-office application and the correspondent. 4. For From Message Partners , determine whether to use First In First Out (FIFO) order. The order in which messages are processed affects how Alliance Access will process the messages from the back-office application. For more information about FIFO affects the use of the sliding window in the SOAP host adapter, see "Window Size" on page 596. 5. Verify the settings of the following system management parameters suit the requirements of the back-office application: • File Digest Algorithm 6. F.5.5 Ensure that payload files do not exceed 250 MB. Recovery of a SOAP Session Introduction This section describes how Alliance Access recovers sessions with the SOAP host adapter. Session Rebuild In the case of an Alliance Access restart, Alliance Access resumes the traffic as if nothing happened. Alliance Access rebuilds the SOAP session and resets it in the state that it was before the Alliance Access restart. The emission and reception window is rebuilt in such a state that: • the messages being sent or received are in the window • the messages waiting acknowledgement are identified The SOAP host adapter sends an error to the back-office application when: • a message sent by the back-office application is not within the window • the messages that the back-office application is acknowledging are not present in the window Messages re-sent with Possible Duplicate Emission When, at session closure, messages sent by Alliance Access to the back-office application have not been acknowledged yet, the session is aborted, and these messages have their Network Status set to "Network Aborted". The messages are requeued in the exit point. If the back-office application requests these messages again, then they are re-sent with a possible duplicate emission indication when the session is re-opened. 15 July 2011 595 Alliance Access 7.0.20 F.5.6 Window Size F.5.6.1 Sliding Window Description of a sliding window The SOAP Host Adapter implements a sliding window mechanism. A sliding window defines the boundary and size of a range of actions within which there are actions waiting to be completed. For example, if the window size is 2 means that there are exactly two actions pending completion A window of W elements means that Alliance Access can process W actions simultaneously, and that Alliance Access starts a new action only when it has processed all the W actions successfully A direct consequence of this mechanism is that while the range is bound, the number of concurrent actions can be as small regardless of the actual window size. For example, the number of concurrent actions can be one action even if the window size is 5. First-in-first-out (FIFO) order The actions to be processed have a precise sequence number. When the actions are run in first-in-first-out (FIFO) order, then the sliding window behaves as a counting window. Therefore, there is just a count of the actions pending completion, without any boundary. However, if actions are not processed in FIFO order, then the window enforces a boundary to the range of the actions that are pending completion. Example In the diagrams in this example, the following conventions are used: • "C" means "Completed", • "W" means "Waiting for completion" • "N" means "Not started" • Actions are numbered from 1 to n For example, the size of the window is 5: 11 12 13 14 15 16 17 18 19 20 21 C C C W W W W W N N N N Window = 5 596 D0540143 10 System Management Guide Appendix F - Connection Methods in AI Action 15 is completed. The window does not slide to the right because the window size of 5 specifies that all 5 actions must be completed before another action starts: 11 12 13 14 15 16 17 18 19 20 21 C C C W W C W W N N N N D0540144 10 Window = 5

7-0-saa-sys-man-guide-pdf-free

Related documents

Products

Support

7-0-saa-sys-man-guide-pdf-free

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib