7 0 Saa Sys Man Guide

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
Table of Contents
.Preface .............................................................................................................................................................................9
Part A – Introduction ........................................................................................................................................11

1 Understanding the Basics ......................................................................................................................... 13
1.1 The Alliance Access Options ................................................................................................................. 13
1.2 Signing on to Alliance Access ............................................................................................................... 13
1.3 The Access Control Window ................................................................................................................. 15
1.4 The File Menu .......................................................................................................................................... 17
2 Using Applications ....................................................................................................................................... 24

2.1 Running Applications .............................................................................................................................. 24
2.2 Standard Menus ...................................................................................................................................... 27
2.3 Shortcut Menus ....................................................................................................................................... 29
2.4 Printing Reports ....................................................................................................................................... 30
2.5 Printing Messages ................................................................................................................................... 31
2.6 Entering Dates and Times ..................................................................................................................... 32
2.7 Sorting Items ............................................................................................................................................ 32
2.8 Rearranging Columns ............................................................................................................................. 33
2.9 Selecting a File ........................................................................................................................................ 35
Part B – Housekeeping Tasks ..................................................................................................................37

3 Installing the SWIFT Alliance Bank File .............................................................................................. 39
3.1 Alliance Bank Files .................................................................................................................................. 39
3.2 Options for Installing an Alliance Bank File ......................................................................................... 39
3.3 What Happens During Bank File Installation ...................................................................................... 41
3.4 Download an Alliance Bank File ........................................................................................................... 42
3.5 Install an Alliance Bank File Immediately ............................................................................................ 43
3.6 Loading the Bank Files from Disk ......................................................................................................... 44
4 Installing Message Syntax Tables ......................................................................................................... 46

4.1 Message Syntax Tables ......................................................................................................................... 46
4.2 Setting a Default Message Syntax Table ............................................................................................ 47
5 Creating and Configuring Your Logical Terminals ........................................................................ 49

5.1 Creating Logical Terminals .................................................................................................................... 49
5.2 Assigning a Message Syntax Table ..................................................................................................... 50
5.3 Selecting the Window Size .................................................................................................................... 51
5.4 Automatic Logical Terminal Allocation ................................................................................................. 52
6 Managing the MX Message Standards ................................................................................................ 54

6.1 Viewing and Printing MX Message Standards ................................................................................... 54
6.2 Install an MX Message Standard .......................................................................................................... 55
6.3 Remove an MX Message Standard ..................................................................................................... 56
2 System Management Guide

Table of Contents
7 Installing Value-Added Services ............................................................................................................ 57

7.1 FINCopy Service ..................................................................................................................................... 57
7.2 Installing and Removing Value-Added Service Parameter Files ..................................................... 59
7.3 Activating and Deactivating Value-Added Services ........................................................................... 61
7.4 Assigning a Value-Added Service to a Destination ........................................................................... 62
7.5 Value-Added Service Destinations Window ....................................................................................... 63
8 Assigning Routing Keywords ................................................................................................................. 65

8.1 Procedure for Assigning Routing Keywords ....................................................................................... 65
9 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 Housekeeping Mode and Operational Mode ...................................................................................... 71
10.2 Starting the Alliance Access Servers ................................................................................................... 72
10.3 Stopping the Alliance Access Servers ................................................................................................. 72
10.4 Restarting the Alliance Access Servers ............................................................................................... 73
10.5 Extended Reporting at Startup of Alliance Access ............................................................................ 74
10.6 Stopping and Restarting Components ................................................................................................. 74
11 Managing Alliance Access Security ..................................................................................................... 77

11.1 Listing Components ................................................................................................................................ 77
11.2 Defining Units ........................................................................................................................................... 78
11.3 Operator Profiles ..................................................................................................................................... 80
11.4 Modifying Operator Profiles ................................................................................................................... 83
11.5 Adding New Operator Profiles ............................................................................................................... 84
11.6 Predefined Operators and New Operators ......................................................................................... 85
11.7 Defining Operators .................................................................................................................................. 85
11.8 Setting Up Local Security Officers ........................................................................................................ 88
11.9 Approving and Enabling Operator Definitions .................................................................................... 90
11.10 Modifying Operators ............................................................................................................................... 92
11.11 Listing Operators ..................................................................................................................................... 93
11.12 Creating Operator and Profile Details Reports ................................................................................... 97
11.13 Disabling Operators ................................................................................................................................ 98
11.14 Removing Operators ............................................................................................................................... 99
11.15 Resetting Operator Passwords ............................................................................................................. 99
11.16 Resetting Security Officer Passwords ............................................................................................... 100
11.17 User Access Security ........................................................................................................................... 101
11.18 Modifying Security Parameters ........................................................................................................... 101
11.19 Security Parameter Details Window ................................................................................................... 110
11.20 Restricting Operator Functions ........................................................................................................... 112
11.21 Configuring Authentication Servers .................................................................................................... 113
15 July 2011 3
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 Set up SWIFTNet Profiles .................................................................................................................... 128
15.2 Assigning SWIFTNet Connections to SWIFTNet Profiles .............................................................. 134
15.3 Enabling and Activating SWIFTNet Profiles ..................................................................................... 139
15.4 Set Up Input Channels ......................................................................................................................... 140
15.5 Set Up Output Channels ...................................................................................................................... 145
16 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 Event Distribution .................................................................................................................................. 171
18.2 Alarm Distribution .................................................................................................................................. 178
18.3 Printing Reports ..................................................................................................................................... 184
18.4 Alarm Scripts .......................................................................................................................................... 184
19 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 The Correspondent Information File .................................................................................................. 215
20.2 Running the Correspondent Information File Application ............................................................... 216
20.3 Displaying Records ............................................................................................................................... 216
20.4 Searching for Correspondents ............................................................................................................ 220
20.5 Correspondent File Window - Search Results ................................................................................. 225
20.6 Creating Correspondent Records ....................................................................................................... 226
20.7 Modifying Correspondent Records ..................................................................................................... 234

Table of Contents
20.8 Activating and Deactivating Correspondents .................................................................................... 235

20.9 Removing Correspondent Records .................................................................................................... 236
20.10 Managing Aliases .................................................................................................................................. 236
20.11 Managing Currency Records ............................................................................................................... 239
20.12 Managing Country Records ................................................................................................................. 241
21 Managing Message Partner Profiles .................................................................................................. 243

21.1 Application Interface ............................................................................................................................. 243
21.2 Message Partners and Message Partner Profiles ........................................................................... 243
21.3 Message Flow in the Application Interface ....................................................................................... 244
21.4 Connection Methods ............................................................................................................................. 245
21.5 Message Partner View ......................................................................................................................... 249
21.6 Status of Message Partner Sessions ................................................................................................. 251
21.7 Preparing the Application Interface for a Transfer Session ............................................................ 251
21.8 Creating a Message Partner Profile ................................................................................................... 252
21.9 Specifying the Connection Method ..................................................................................................... 253
21.10 Specifying the Emission Parameters ................................................................................................. 281
21.11 Specifying the Reception Parameters ............................................................................................... 285
21.12 Specifying Local Authentication .......................................................................................................... 291
21.13 Modifying a Message Partner Profile ................................................................................................. 296
21.14 Automatic Logical Terminal Allocation ............................................................................................... 297
21.15 Typical Configurations for Message Exchange Sessions ............................................................... 298
21.16 Configuration for Sanctions Screening over SWIFT ........................................................................ 300
22 Managing Exit Point Profiles ................................................................................................................. 302

22.1 Displaying Exit Point Details ................................................................................................................ 302
22.2 Exit Point Window ................................................................................................................................. 302
22.3 Exit Point Details Window .................................................................................................................... 303
22.4 Defining an Exit Point ........................................................................................................................... 304
22.5 Modifying Exit Point Routing ............................................................................................................... 305
22.6 Removing an Exit Point Profile ........................................................................................................... 305
23 Configuring Queues ................................................................................................................................... 307

23.1 Queues and Routing ............................................................................................................................. 307
23.2 Displaying Queues ................................................................................................................................ 307
23.3 Displaying Queue Details ..................................................................................................................... 308
23.4 Holding and Releasing Queues .......................................................................................................... 311
23.5 Modifying the Queue Threshold .......................................................................................................... 311
23.6 User-Defined Queues ........................................................................................................................... 311
24 Message Routing ........................................................................................................................................ 314

24.1 Message Routing Concept .................................................................................................................. 314
24.2 Routing Schemas .................................................................................................................................. 314
24.3 Routing Keywords ................................................................................................................................. 317
24.4 Routing Rules ........................................................................................................................................ 318
24.5 Using the Criteria Definition Window ................................................................................................. 328
15 July 2011 5
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 Requesting a Report of Current Delivery Subsets ........................................................................... 344
25.2 Defining a Future Delivery Subset ...................................................................................................... 344
25.3 Example of Adding a Future Subset .................................................................................................. 354
25.4 Sending a Delivery Instructions Redefinition Request (MT 047) ................................................... 354
25.5 Synchronising Delivery Subsets ......................................................................................................... 355
25.6 Sharing Delivery Subsets ..................................................................................................................... 355
26 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 Message Throughput: A Definition ..................................................................................................... 362
27.2 Configuring Event Distribution ............................................................................................................. 362
27.3 Configuring the _SI_from_SWIFT Queue ......................................................................................... 363
27.4 Configuring the _SI_to_SWIFT Queue Threshold ........................................................................... 364
27.5 Configuring Two Logical Terminals for Input and Output ............................................................... 365
27.6 Configuring Three Message Partners ................................................................................................ 365
Part D – Appendices .......................................................................................................................................367

.Appendix A Default Profiles ...............................................................................................................................369
A.1 Standard Default Profiles ..................................................................................................................... 369
A.2 Printout of Default Routing Rules ....................................................................................................... 388
.Appendix B Default Settings ..............................................................................................................................389
B.1 Types of Settings ................................................................................................................................... 389
B.2 Default Event Distribution .................................................................................................................... 390
B.3 Default Alarm Distribution .................................................................................................................... 390
B.4 Default Operator Profiles ..................................................................................................................... 390
B.5 Default Queue Visibility and Modification Rules ............................................................................... 391
B.6 Default Message Partner Profiles ....................................................................................................... 393
B.7 Default Security Configuration Parameters ....................................................................................... 393
B.8 Default System Configuration Parameters ........................................................................................ 393
.Appendix C Queues and Message Processing Functions ...................................................................394
C.1 List of System Queues ......................................................................................................................... 394
C.2 List of Exit Queues ................................................................................................................................ 403
C.3 Printout of Default Queues .................................................................................................................. 409
C.4 OI_to_OTHER Queue .......................................................................................................................... 410
.Appendix D Message Formats Used in AI ....................................................................................................411
D.1 PC Connect (DOS-PCC) ...................................................................................................................... 411

Table of Contents
D.2 RJE .......................................................................................................................................................... 414

D.3 MERVA/2 Format .................................................................................................................................. 417
D.4 Common Application Server (CAS) Format ...................................................................................... 418
D.5 XML Formats ......................................................................................................................................... 425
D.6 MQ-MT Format ...................................................................................................................................... 534
D.7 Codes in the Trailer (Block S) ............................................................................................................. 538
.Appendix E Message Validation and Disposition .....................................................................................543
E.1 Message Validation and Disposition Overview ................................................................................ 543
E.2 Levels of Validation ............................................................................................................................... 544
E.3 Message Validation for RJE, DOS-PCC, and MERVA/2 Messages ............................................. 546
E.4 Message Validation for XML Messages ............................................................................................ 547
E.5 Message Validation for CAS Messages ............................................................................................ 548
.Appendix F Connection Methods in AI ..........................................................................................................553
F.1 Direct FileAct .......................................................................................................................................... 553
F.2 File Transfer ........................................................................................................................................... 564
F.3 Interactive ............................................................................................................................................... 573
F.4 Print ......................................................................................................................................................... 580
F.5 SOAP ...................................................................................................................................................... 587
F.6 WebSphere MQ ..................................................................................................................................... 616
.Appendix G Parameter Files in AI ....................................................................................................................633
G.1 Creating an Input Parameter File ....................................................................................................... 633
G.2 Authenticating Input Parameter Files ................................................................................................. 634
G.3 Specifying the Parameter File in the Message Partner Profile ...................................................... 635
.Appendix H Transmission and Delivery of FINCopy Messages .........................................................636
H.1 FINCopy Service ................................................................................................................................... 636
H.2 Failure Conditions ................................................................................................................................. 637
.Appendix I The FINCopy Server .......................................................................................................................638
I.1 Processing an Incoming MT 096 ........................................................................................................ 638
I.2 Processing an Outgoing MT 097 ........................................................................................................ 639
I.3 Re-authentication of Failed Messages .............................................................................................. 639
.Appendix J Handling Double-Authenticated Messages with FINCopy ...........................................643
J.1 Message Flow ........................................................................................................................................ 643
J.2 Implementation ...................................................................................................................................... 646
J.3 Examples of MT 096 and MT 097 with PKI Signatures .................................................................. 648
.Appendix K Command-line Tools ....................................................................................................................652
K.1 getmesg .................................................................................................................................................. 652
K.2 messageTool ......................................................................................................................................... 654
K.3 reset_mp ................................................................................................................................................. 655
K.4 systeminfo (UNIX only) ......................................................................................................................... 656
K.5 saa_supportinfo ..................................................................................................................................... 656
K.6 saa_system integrity ............................................................................................................................. 659
K.7 saa_query ............................................................................................................................................... 660
15 July 2011 7
K.8 sa_split .................................................................................................................................................... 662

.Legal Notices .............................................................................................................................................................664

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

Part A - Introduction
Part A
Introduction
15 July 2011 11

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
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 Sign On .

Note 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.
7. 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 OK .
Note 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.
1.3 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
• 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

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 Modify to confirm your changes.
Note 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.
15 July 2011 17
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 OK to save the printer settings.
Note 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. Select Page Setup... from the File menu.

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 OK to save the page settings.
Note If you change the page settings, then you must quit any applications that are
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 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.
15 July 2011 19
3. Click OK to save the font settings.
Note If you change the font settings, then you must quit any applications that are
the applications.
1.4.3 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 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.
2. 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.

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. If you want items listed in any window to appear within a grid, then check Main lists have a
grid aspect.
15 July 2011 21
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.
Note This command is not available if your operator definition is set to use One-Time or
LDAP passwords.
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. Click OK .
1.4.5 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.

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. 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.
15 July 2011 23
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:

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.
2.1.2 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:
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.

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:

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.
2.1.4 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
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.

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:
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
15 July 2011 27
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.
Refresh Now Refresh a screen with the latest data.
Exit Quit the application.
2.2.2 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.

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
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:
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.

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:
• Print prints the report out
• Next Page shows the next page of the report
• Prev. Page shows the previous page of the report
• Two Page shows two pages side by side
• Zoom In shows an enlarged view of the report
• Zoom Out shows a reduced view of the report
• Close 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 sub-
directory, which is within the directory where Alliance Access is installed on your machine.
8. Click OK .
2.5 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
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.

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
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. Select Save Current Settings from the File menu to save the new position of the column.

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
Some commands enable you to specify whether a file is located on the Workstation or on the
server.

Part B - Housekeeping Tasks
Part B
Housekeeping Tasks
15 July 2011 37

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
Note 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.
2. 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 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.
2. 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 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".
2. Load the Bank Update File while the server is running in operational mode.

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
Note 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.
3.4 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>

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:

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.
15 July 2011 43
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 Required location
Full Bank File $ALLIANCE\data\BIC
Bank Update File $ALLIANCE\data\UpdateBIC
6. Click Continue . A message confirms that the file is being loaded.
Important Do not stop the Alliance Access servers until the installation of the Bank File is
completed.
7. 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:

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.

5. In the File location field, use the browse button ( ... ) to locate the files.
6. Click OK and then Continue .
Note 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.
7. 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
4 Installing Message Syntax Tables

Introduction
This section contains instructions for installing and assigning Message Syntax Tables using the
SWIFT Support application.
Note To perform the tasks described in this section, the Alliance Access servers must be
restarted in Housekeeping mode.
4.1 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:

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.

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 Install to install the table.
Note If you are running Alliance Access in Low Speed Mode, then you must single-
click the Message Syntax Table window, or press F5 to refresh it.
4.2 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:

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.
15 July 2011 47
5. From the Mstv Id menu, select Set Default Live or Set Default T&T as appropriate.

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 To create logical terminals, the servers must be running in Housekeeping mode.
5.1 Creating Logical Terminals

To create a logical terminal:
2. Start an Alliance Workstation.
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.
15 July 2011 49
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.
click 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 Do not assign a new Message Syntax Table to a live logical terminal before it
actually becomes live on the network.

To assign a message syntax table:

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.
5.3 Selecting the Window Size

Overview
This section describes how to select the window size for your logical terminal.
To select the window size:

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
Note This value must match the FIN window size requested to SWIFT for the logical
terminal.
6. From the Logical Terminal menu, select Modify.
5.4 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 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.
5.4.2 Enabling Automatic Logical Terminal Allocation

To enable automatic logical terminal allocation:
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.

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.
15 July 2011 53
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:
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)

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.
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:
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.
15 July 2011 55
6.3 Remove an MX Message Standard

To remove a Message Standard:
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.

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 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.
7.1 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
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
Y Copy Facility
SWIFT
Sending Network Receiving
D0540048
Institution Institution
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.

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
T Copy Facility
SWIFT
Sending Network Receiving
D0540049
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 For T-Copy mode, only participants have to install the value-added service
parameter file. The central institution does not have to install it.
15 July 2011 59
7.2.1 Installing a Value-Added Service Parameter File

To install a value-added service parameter file:
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 Install .
click the Value-Added Service window or press F5 to refresh it.
7.2.2 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:

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 remove.
5. From the Value-Added Service menu, select De-install.
click the Value-Added Service window or press F5 to refresh it (Windows
servers only).
7.3 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 For T-Copy mode, only participants have to activate a value-added service. The
central institution does not have to perform this task.
7.3.1 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 Value-
Added Service Parameter File" on page 60.
To activate an installed value-added service:

4. Select the service that you want to activate.
5. From the Value-Added Service menu, select Activate. The State field in the Value-
Added Service window changes to Active for the selected service.
7.3.2 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
To deactivate an active value-added service:

4. Select the service that you want to deactivate.
5. From the Value-Added Service menu, select Deactivate. The State field in the Value-
Added 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:

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 Value-
Added 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.
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.

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
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.

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:
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.
15 July 2011 65
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.

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

Part C - Configuring Alliance Access
Part C
Configuring Alliance Access
15 July 2011 69

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
– modify active routing rules
Note No scheduled processes take place when the servers are running in housekeeping
mode.
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.
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.
10.3 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 If there is no active routing schema when stopping the Alliance Access servers,
then a restart is only possible in housekeeping mode.

To stop the Alliance Access servers:

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:

2. From the File menu, select Restart Alliance. The Restart Alliance dialog box appears.
3. Select Manual as the Restart Operating Mode option.
15 July 2011 73
4. Select either Operational or Housekeeping as the Restart mode option.
5. Click Restart .
Note 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.

To stop a component in operational mode:

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:

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
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:

• From the System Management application, select the components that you want to stop
and click Stop Component from the File menu.

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
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

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:
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.
15 July 2011 79
Note 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.
11.3 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:

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.

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.
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.
15 July 2011 81
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:
Permission Description
Bypass Verification Prohibited is selected and the column to the right is empty. This means
CCY/Amount that nothing is prohibited. The operator can bypass verification for a
message of any currency and any amount.

Permission Description
Bypass Authorisation Prohibited is selected and the column to the right is empty. This means
CCY/Amount that nothing is prohibited. The operator can bypass authorisation for a
message of any currency and any amount.
Bypass Verification Allowed is selected and 999 appears in the column to the right. This
SWIFT FIN User MT 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 You cannot transfer applications between the Selected and Available lists by
double-clicking them.
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 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.
6. From the Profile menu, select Modify.
15 July 2011 83
Note During an upgrade, profiles remain unchanged even if Applications or

Functions have been modified.
11.5 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.
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.

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:
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.
15 July 2011 85
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. Select the Application check box if the user being defined is an application that will
connect to Alliance Access.

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 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.
15 July 2011 87
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
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:

• From the Operator menu, select Add.
11.8 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.

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
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.

By default, left security officer can left-approve an operator, and right security officer can right-
approve 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 left-
approve 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:
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 two-
character, 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 right-
approve:
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.
15 July 2011 91
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 two-
character, 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 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.

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
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 All the operators that need approval by the left security officer, or by an
Approval operator entitled to left-approve
Wait RSO All the operators that need approval by the right security officer, or by an
Approval operator entitled to right-approve
From the Enable Status field, select one of the following:
Select To see
Any All operators, whatever status they have
Enabled All the enabled operators
Disabled All the disabled operators

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:
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 All the operators who are authenticated by the One-time Password
Password authentication method
4. Click the Profiles tab.
15 July 2011 95
From the Profile Assignment field, select one of the following:
Select To see
Any Profile Operators who use the profile name entered in the Profile field. The wildcard
Matching String 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 Operators who use the profile(s) in the Profiles/Selected column. Profile
Selected List 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.
5. Click the Units tab.
From the Unit Assignment field, select one of the following:
Select To see
Any Unit Matching Operators who use the unit name entered in the Unit field. The wildcard
String 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 Operators who use the unit(s) in the Units/Selected column. Unit names
List 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.
6. Click the Printers tab (only available for UNIX servers).

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 Search . The operators that meet your search criteria appear within the window.
Note 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
To generate a full operator and profile details report:

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 if you selected Workstation
• Continue 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:

2. Click the operator.
3. From the Operator menu, select Disable.
4. Select a Next Sign On Allowed option.

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:
2. Click the operator.
3. From the Operator menu, select Remove.
4. Click Yes to confirm the removal, or No to stop it.
Note 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:

1. Sign on to Alliance Access as left security officer, or as an operator entitled to left-approve.
4. Double-click the operator password that you want to reset.
15 July 2011 99
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 right-

approve.
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:
1. Sign on to Alliance Access as right security officer.
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.

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.
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

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. The full path name of the user-defined script executed on
Path of Script File 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: The full path name of the user-defined UNIX shell script executed
Path of Script File 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 Backup integrity Specifies the type of digest that is calculated to ensure the
integrity 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 Method Possible values are:

Archive
• 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.

Message Check authorisation Indicates whether the existence of an RMA authorisation is

exist 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.
• Message Text Journalised
• Message Text Not Journalised

Default value: Message Text Journalised.
Message Message Repair Indicates the type of action that is performed by default on the
Action 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 Specifies whether the SWIFT Interface component performs a
extraction 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.
• 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


– Modification After Reception Queue for output messages.
Default value: Full.
Message Retrieved Message When set to On, the SWIFT Interface component extracts the
Extract 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.
• 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.
• 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.
• 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 Software Owner Specifies the operator profile that is assigned as the owner of the
Profile 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.

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.
• 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.
• 0 through 100
Default value: 5.
Password Min Pwd Length Minimum length of the user password.

• 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.
• 0 through 20
Default value: 10.
Password Reset Peer Officer Allows the left security officer to reset the right security officer's
Passwo 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.
• Yes
• No
Default value: No.
Password Sec Officer One Time Activates the use of one-time passwords for the security officers.
Pwd If this parameter is set to Yes and a primary authentication server
15 July 2011 105


has been configured, then the left security officer and right
security officer can use one-time passwords.
• 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.
• Yes
• No
Default value: No.
Password User Period Number of days after which the user password has to be
changed.
• 0 through 120
Default value: 30.
Reports Root Path for Report The path name which is the top level of the directory tree where
File 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 Controls the explicit request to confirm the rejection of
Confirmation 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.
• 0 through 3600
Default value: 1800.
If 0 is selected, then the workstation is not signed off
automatically.

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.

• 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.
• 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.
• 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.
• 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.
• 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


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 high-
throughput configurations.
System Software Check at Determines whether the system runs the Integrity Verification Tool
Startup when Alliance Access is started, to check the integrity of the
Alliance Access software.
• Yes
• No
Default value: Yes
User Mode Housekeeping User In housekeeping mode, either a Single Operator is allowed to sign
Mode on or Multiple Operators are allowed to sign on.
• Single
• Multiple
Default value: Single.
Alliance Access must be restarted for changes to this parameter
to take effect.

User Space Root Path for User The location on the Alliance Access server where the user space
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:

1. Sign on to Alliance Access as left security officer.
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.
15 July 2011 109

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.

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

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 operator-
related 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.

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:

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.
15 July 2011 113

Note 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.
3. 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 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.

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

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:

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.

Note 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.
3. 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. Click Approve to approve the changes.
15 July 2011 117

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
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.

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
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

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 OK .
6. Add either the self-signed SSL certificate or the SWIFTNet Certification Authority certificate
to the keystore.
Procedure on Oracle Solaris

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

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.
Sender/Receiver name
Service Name = swift.fin
SWIFTNet Signature (PKI)
Message
(Authoriser DN)
MT
Message
(unchanged) MT103
Sender BIC
Receiver BIC
D0540083
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

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.
Sender/Receiver name
Service Name = "SWIFTNet Business"
SWIFTNet Signature (PKI)
Message
(Authoriser DN)
MX
Message
ifds.001.001.01
D0540084
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.

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:
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

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:
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.

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 Once you have defined a printer, it must be enabled under UNIX.
15 July 2011 125

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.

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.
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.
15 July 2011 127

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:
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.

Defining SWIFTNet Profiles
4. Enter the details of the emission profile. For details, see "Emission Profile Details - Profile
Details Tab" on page 129.
Note 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.
5. 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

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.

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

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:
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.

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

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 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

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

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
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.
Note The Authoriser DN must belong to the same institution as the Requestor DN
(that is, the BIC8 in both DNs must be the same).
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.

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.

A list of available SWIFTNet connections appears.
15 July 2011 137

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
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 Real-
time, 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 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.
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.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

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:

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.
15.4 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).

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

Procedure
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. Click Create on SWIFTNet .

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

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. Click Yes .
15 July 2011 143

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

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

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. Click Yes .

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
2. Select Output Channel from the View menu.

The Output Channel window appears, showing the output channels defined.
15 July 2011 145

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

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

3. Select the output channel to be removed.
4. Select Remove from the Output Channel menu.

A confirmation window appears.

5. Click Yes .
15 July 2011 147

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.

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

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
16.2.3 Adding a SWIFTNet Connection

To add a SWIFTNet connection:
2. Stop the SWIFT Interface Services (SIS) and SWIFTNet Interface Services (SNIS)
components as described in "Stopping and Restarting Components" on page 74.

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.
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)

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

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.

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:

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
5. The information in the following fields can be updated (depending on your configuration):
• Hostname
• Port Number
15 July 2011 153

• 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.
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:


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.

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:


4. Click the connection marked as Not reliable and select Mark Connection as Reliable from
the SWIFTNet Connection menu.
16.3 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

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.
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.
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.

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.
Note You can schedule different actions for logical terminals. For more information, see
"Scheduling FIN Select or Logout from SWIFT" on page 205.
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 Use specific The result is

Authoriser DN 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

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:
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:
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
3. 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 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.

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

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
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
Archive Backup The Oracle database requires this parameter to create the Data Pump files
Dir Object 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 The Oracle database requires this parameter to create the Data Pump files
Object containing the backups of the Alliance Access database.
Maximum value: 30.
operation.

Location This parameter defines the file directory wherein the Alliance Access backups are
Backups 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.
operation.
Location This parameter defines the file directory remotely accessed from the database host
Backups DB 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.
operation.
17.3.4 Batch Input

List of batch input parameters
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 - Automatic Input Backup Directory.

Backup Dir All files in this directory that are older than the Batch Input History Period are
deleted.
Default: C:\Alliance\Access\usrdata\FTA\back
Automatic - Error Automatic Input Error Directory.

Dir 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
Automatic - The Session Autostarter Polling Timer in seconds. Default value: 60.
Polling Timer 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.
15 July 2011 161

17.3.5 Batch Output

List of batch output parameters
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 Specifies whether Alliance can wait for Local Transfer Agent completion before
mode 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.
Location Location of the daily Messages database files. A change to this parameter is taken
Messages 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 Location of the daily Journal Events database files. A change to this parameter
Events 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
• 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
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

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
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 Alliance Access shuts down when the free space of the Recovery Backup Disk
Shutdown - MB becomes less than this number of megabytes. If the value is 0, then no action is
taken.
This parameter is available when 14:DATABASE RECOVERY is licensed.
Recovery Alliance Access issues a warning when the free space of the Recovery Backup
Warning - MB Disk becomes less than this number of megabytes. If the value is 0, then no action
is taken.
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.
Shutdown - Shutdown Alliance Access when available space on the disk of the source tree is
Release Dir 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.
If the value is 0, then no action is taken.
Warning - Alliance Access issues a warning when available space on the disk of the Release
Release Dir Directory is less than this value.
Default value: 50000 (Kbytes).
15 July 2011 163

UNIX only: Alliance Access issues a warning when available space on the /tmp disk is less
Warning - Printer than this value (in Kbytes).
Spool Default value: 10000. Minimum: 1024. Maximum: 200000.
17.3.9 Display Format

List of display format parameters
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
FIN User Specifies whether to display or print the FIN User Header (block 3) of MT messages.
Header
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.

17.3.11 Emission
List of emission parameters
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
SNMP Max Indicates the maximum size of the event text distributed to SNMP managers. 0 means
Event Size that there is no maximum size. Default value: 2000.
17.3.13 File
File parameter
File Digest Indicates the default file digest algorithm that Alliance Access uses to compute the
Algorithm 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
Expansion Specifies the language that message expansion fields are displayed in. Default value:
Language English.
A change to this parameter takes effect when an application is restarted.
LT load Enables automatic logical terminal allocation.

balancing
• 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

RMA Specifies whether RMA Authorisation is required for FIN Test and Training
authorisation messages. Possible values are:
for T&T
• 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 Controls the calculation of the Common Reference, which is part of field 22 of Block
Calculation 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
SWIFTNet Maximum delay (in seconds) that Alliance buffers an input message before it is
Batching Timeout 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 Maximum number of FIN APDUs that can be sent in a single DATA PDU. SWIFT
batch count 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.

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 Specifies the number of attempts that are allowed to reconnect a failed
Retries 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 Specifies the duration (in minutes) for which attempts to reconnect a failed
Time communication session with the SWIFT network are made. Default value: 30.
to take effect.
Usersync - Retry Specifies the time-out period (in seconds) between reconnect retries. Default value:
Timer 120.
to take effect.
Delivery Notif via Specifies whether SWIFTNet delivery notifications for InterAct or FileAct messages
SysMsg 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
17.3.16 Performance
List of performance parameters
Active Controls whether correspondents are checked to see whether they have an active
Correspondent 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 Controls whether keywords are extracted from incoming (output) MT messages.
Extraction 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 Disk I/O in MB/sec used to read from the database disks when a Recovery Backup
Rate 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 Controls whether the writing of some interventions is suppressed. The possible
Interventions 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.
15 July 2011 167

MX Keyword Controls whether keywords are extracted from incoming (output) MX messages.
Extraction The possible values are "On" or "Off". Default value: On.
The SWIFTNet Interface Services must be restarted for the changes to this
Routing Controls what types of interventions are suppressed. The possible values "All",
Intervention "System generated only", or "None". Default value: None.
17.3.17 Print
List of print parameters
Message Search Specifies the maximum number of items that can be printed in a Message Search
Results Report. Default value: 1024. The value "0" means that no limit is set.
Skip Specifies whether Printer message partners print notifications without system or
Interventions 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 Specifies whether Printer message partners print messages in an ST200-like

Format 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
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
Default HQ for Specifies the receiver for system messages 074. Default value: SWHQBEBBBCT.
MT074
Default HQ for Specifies the receiver for system messages 090. Default value: SWHQNLNLXXX.
MT090

17.3.20 RMA
RMA parameter
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
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
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.

17.3.23 Traffic Recon

Traffic Recon parameter
Delivery Notif If set to Yes, then Traffic Reconciliation generates notifications for each matched
message instance. Default value: Yes.
15 July 2011 169

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:
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.
Input Message Limits the number of messages that Alliance Access reads per second from all the
Rate Limit 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 - The time interval, in seconds, after which the first attempt to reopen the
Initial communication session with WebSphere MQ is made in case of a broken
connection. Default value: 60.
Recovery Time - The increase of the time interval, in seconds, between consecutive attempts to
Increment reopen a WebSphere MQ session. Default value: 30.
Recovery Time - The maximum time interval, in seconds, between consecutive attempts to reopen a
Max WebSphere MQ session. Default value: 600.

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

To display event types:

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.

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

• 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.

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

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
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.

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:

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:

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. Click Distribute Alarm and select True to broadcast the alarm.
15 July 2011 177

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 .
18.2 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:
Field OID Description
Unique identifier of the .1 Differentiates events coming from more than one Alliance instance
SAA instance
Date .2 Date, expressed as dd/mm/yyyy
Time .3 Time, expressed as hh:mm:ss

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:

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

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.

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

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:
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.

6. Click Modify .
18.2.7 Creating Distribution Lists

To create distribution lists:
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
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:

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.
15 July 2011 183

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

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 During any period when the servers are running in housekeeping mode, no
scheduled actions take place.
19.1 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 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.
15 July 2011 185

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:

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:
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.

The following window appears (with the year listed here if it has been defined):
3. From the Year menu, select New.

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.
15 July 2011 187

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:

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.

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

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

• 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. From the Year menu, select Add to save the changes.
15 July 2011 191

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 Show Legend button text
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 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. Select Remove from the Calendar menu.

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:

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.
15 July 2011 193

Note When moving applications between the Available and Selected list boxes in
the Profile Details window, you must use the transfer buttons. Do not double-
click an application name to move it between boxes.
4. 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.
Note This is only possible with functions that can be scheduled (for example,
archiving of the Event Journal).
9. Click OK .
10. From the Profile menu select Modify, to save the profile.

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 Only calendars that have the current year defined are available for selection.
3. 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

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:

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.

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 Since events are archived for a full day, it is not possible to archive the events
from the current day.
5. In the Schedule Details/Schedule Category list, select a schedule.

Select from:
• Every day
• Specific day
• Business day
• Business week
• Business month.
Note Changing this field deletes any previously scheduled actions.
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
15 July 2011 197

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 Store to save the settings.
9. Click Quit 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

• Specific day
• Business day
• Business week
• Business month

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.
Note 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.
8. When you have completed the schedule details, click Store to save the settings
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

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:

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 If you intend to copy the backup to tape or a hard disk, then make a note of
this directory path for future reference.
6. In the Schedule Category list, select one of the following schedules:
• Every day
• Specific day
• Business day

• Business week
• Business month
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.
Note 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.
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

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

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 If you intend to copy the backup to tape or a hard disk, then make a note of
this directory path for future reference.
6. In the Schedule Category list, select one of the following schedules:
• Every day
• Specific day
• Business day

• Business week
• Business month
7. Specify at least one action for the schedule, as follows:
Field Action

The available choices depend on the Schedule Category that you selected.
Earliest Specify the time (HH:MM:SS) at which the action is to occur.

Start
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.
Note 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.
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:

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.
15 July 2011 203

4. Select a category in the Schedule Category list.

Select from:
• Every day
• Specific day
• Business day
• Business week

Schedule Category option selected).
• in the at field, specify the time (HH:MM:SS) at which the action is to occur.
7. When you have completed the schedule details, click Store to save the settings, and then
click Quit to quit the dialog box.
19.2.9 Scheduling Alliance Access Servers to Restart

To schedule the Alliance Access servers to restart at specific times:
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.

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

Schedule Category list option selected).
• in the at field, specify the time (HH:MM:SS) at which the action is to occur.
8. When you have completed the schedule details, click Store to save the settings, and then
click Quit to quit the dialog box.
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

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

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:
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.

5. Select a category in the Category field list.

The choices available are:
• Every day
• Specific day
• Business day
• Business week
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 The On Every field is disabled if you selected Every Day in the Category field
of the Logical Terminal Details screen.
15 July 2011 207

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:

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.

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

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:

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. 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, 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

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. Enter the scheduling details, that is, when you want the operation to be performed. Click
Store .

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:

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.
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.
15 July 2011 213

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 Store to save
your settings.
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 Specify a threshold (in MB) for the total size of the archived redo log files. If
Size (MB) 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 Specify a threshold (in MB) for the total size of the existing incremental
Total Size (MB) 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.
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.

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.

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

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.

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:
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

20.3.3 Displaying Currencies

To display currencies:
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:
2. Select Country from the View menu. All the country records in the CIF are listed in the

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

• 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.

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. In the Institution field, type the BIC-11 address of the Institution to search for. Use of wild
cards is allowed.
15 July 2011 221

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. Click the Status tab.

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

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.

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

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.

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.
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.
15 July 2011 227

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. Click the Other tab.

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.
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.
15 July 2011 229

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.
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.

Note 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.
4. 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:
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.
15 July 2011 231

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:

Institution PARENT to Departments A and B
CHILD to Institution
Department A Department B
PARENT to Individuals A and B
Individual 1 Individual 2 CHILD to Departmment B
D0540051
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

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.
Institution PARENT to Departments A and B
Department A Department B
Same correspondent profile as Institution Same correspondent profile as Institution
D0540052
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 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.
20.7 Modifying Correspondent Records

Overview
If necessary, you can modify the details for a specific correspondent in the CIF.
To modify correspondent details:

1. Double-click the correspondent within the Correspondent File window. The
Correspondent Details window appears.

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:

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.
15 July 2011 235

3. Select the correspondents that you want to activate or deactivate.
4. Select Activate or Deactivate from the Correspondent menu.
Note You cannot activate or deactivate a correspondent if that correspondent's

details are being modified at the time.
20.9 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:

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.

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
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

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.

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

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:
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
3. Select Modify from the Currency menu to save the modified record to the CIF.

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

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
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:
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.

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

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
MESSAGE PARTNER
Application
Interface
Alliance MESSAGE PARTNER
AI_from_APPLI
MESSAGE PARTNER
D0540053
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.

Output message flow
OUTPUT SESSION
Application
Interface
exit point 1
D0540054
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
exit point 1 Polling cycle

Application
Interface
exit point 2
exit point 3
D0540055
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

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 Directory Batch

(ST200 PCC)
RJE Directory Batch

(ST200 RJE)
CAS 1/2 Directory CAS Batch

(NDF/NIF)
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
SOAP XML version 2 Revision 2 or NA SOAP

3

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 Purpose
Common Application Server CAS standards 1 and 2 which support the sub-formats ASN.1 or text
(CAS) encoding (only CAS version 2)
used for Network Dependent Format (NDF) or Network Independent
Format (NIF)
15 July 2011 247

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

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 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.
15 July 2011 249

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 file-
output 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.

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 The session is recovering from a session failure, such as an abort request or a system
restart.
21.7 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

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

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.
21.8 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
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.

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

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:

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.

For a description of the fields displayed in this window, see "Print Connection Details
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 In the Number of messages = field, type the number of
are queued at the assigned exit messages that must be queued to trigger a session.
point(s)
One or more specific times of the In the Or at (hh.mm) field, enter the time(s) at which the
day 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

• 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

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

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
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

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

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

• 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

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.
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
Note 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.
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 Value Description
Number of messages = The number of In the Number of messages = field, type the
messages that are number of messages that must be queued to
trigger a session.

Parameter Value Description

queued at the assigned
exit point(s)
Or at (hh.mm) One or more specific In the Or at (hh.mm) field, enter the times (using
times of the day 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 Messages transferred using the CAS 2 protocol are accepted only when Input File
Format Recognition is set to Forced.
15 July 2011 263

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

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

• 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
• 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.

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.
• if before 10:00, ten messages are queued, a session is started
• 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

• 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.
• 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.
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
• 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.

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

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,

To select Interactive as a connection method:

1. Select one of the following directions from the Allowed direction drop-down list:
• 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,
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

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.
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.

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

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 32-
character 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 32-
character 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 5101/tcp
MPconn2 5102/tcp
MPconn3 5103/tcp
MPconn4 5104/tcp
MPconn5 5105/tcp
The connection identifier is the string in the left-hand column, for example, MPconn1. The right-
hand 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 If you change a port number, for example, 5101, then you must inform the relevant
message partner about the change.

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:
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

4. If you selected To Message Partner, then you can select the following options, if required
and appropriate:
Purpose, if selected for:
Parameter MQ-MT XML
Transfer PKI Signatures To transfer PKI signatures Not available for selection.
when sending FIN messages to PKI signatures are always
this message partner. transferred for XML version 2.
Back-office applications must
be ready to receive and store
PKI signatures.
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.
5. 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 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.

7.
Parameter Purpose, if selected Notes
Transfer SAA To transfer The information includes:

Information information about the
Alliance Access • the Alliance Access instance name followed
instance which has by /
processed the
message
• either:
When you select this
option, the Use MQ – exit point that the message was taken
Descriptor field from (emission profile)
appears.
– 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 To send the Alliance If you clear this option, then the MQ Message
Access information in Data part carries the Alliance Access
the MQ Message information.
Descriptor to the For more information, see "MQ Message
message partner Descriptor" on page 623.
8. 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 In the Number of messages = field, type the number of
are queued at the assigned exit messages that must be queued to trigger a session.
point(s)
One or more specific times of the In the Or at (hh.mm) field, enter the time at which the
day 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.
• if ten messages are queued before 10:00, then 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

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 Value To Message From

Partner Message
Partner
FileAct mode Select from: ✓ ✓
• 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.
Chunk Size If you selected Full FileAct mode, then ✓ x

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
Don't Use If you selected Full FileAct mode, and the ✓ x

Segmentation 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.
Input Attachment If you selected Mixed FileAct mode, then x ✓

Directory 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.
Output Attachment If you selected Mixed FileAct mode, then ✓ x

Directory specify the path to a directory on the server
where the payload file is stored
message.

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 & 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

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 Value To message From

partner message
partner
FileAct mode Select from: ✓ ✓
• Full (Default) - to transfer both the

XMLv2 message that contains the file-
transmission 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 If you selected Mixed FileAct mode, then x ✓

directory specify the path to a directory on the server
where the payload file is stored.

Parameter Value To message From

partner message
partner
message.
Output attachment If you selected Mixed FileAct mode, then ✓ x

directory specify the path to a directory on the server
where the payload file is stored.
message.
Extension If you selected Mixed FileAct mode, then ✓ x

you can optionally specify an extension of
the payload file.
6. 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

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.

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. Locate the list Available. This list contains all exit points which are available for assignment
to this message partner.
15 July 2011 283

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.

• 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

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)

• 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

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

– 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

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

• 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

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'.

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

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.

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 32-
character 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 16-
character 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

• 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.

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.
Note 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.
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

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.
Application Interface inbound ep1
Profile: mp3
D0540056
"To and From..."
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.

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..."
Profile: Input _mp1 Profile: Input _mp2

"From..." "To..."
D0540057
mp1 mp2
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.
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.
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

Application Interface inbound Application Interface outbound
Profile: Interactive
"To and From..."
Message Partner
D0540059
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

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

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:
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.
3. Select an exit point from the list.
4. From the Exit Point menu, select Open.
22.2 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.

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

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 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.

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:
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.
22.6 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

To remove an exit point:

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.

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

To display queues:
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 low-
speed 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.

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

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.

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 All exit points are considered as valid routing targets and are therefore not
displayed in the Available/Selected panels.
23.4 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 Only queues which process messages can be held. Queues which create new
messages cannot be held (for example, _SI_from_SWIFT, _AI_from_APPLI).
23.5 Modifying the Queue Threshold

To modify the queue threshold:
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.
23.6 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

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 The name can be up to 20 alphanumeric characters (including underscore

characters, but no leading underscore characters). No spaces are allowed in
the name.
4. 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:

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.

Configuring Queues
Note It is not possible to remove any non-user-defined queues.
15 July 2011 313

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.

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. In the Description field, type a description of the routing schema.
15 July 2011 315

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:

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.

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:

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.
15 July 2011 317

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.

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. 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.
15 July 2011 319

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.

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

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).

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

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).

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

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.

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 user-
defined 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:
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:
2. From the View list menu, select Queue. The Queue - System Management window
appears.
3. Select the relevant user-defined queue to be removed.
15 July 2011 327

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.
24.5 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
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.

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

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

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

<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

Message Routing
Authorising_operator_name
This keyword represents the username of the operator that authorised the instance.
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
Copy_recipient_DN
This keyword represents the recipient DN of the SWIFTNet Copy message or file.
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

Creating_application
This keyword represents the application that created the message instance.
Creating_mpfn
This keyword represents the message processing function that created the message instance.
Creating_operator_name
This keyword represents username of the operator that created the message.
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).
Creation_queue
This keyword represents the name of the queue where the message or message instance was
created.
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).
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.

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).

File_logical_name
This keyword represents the logical name of the file.
File_size
This keyword represents the size of the file in bytes.
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.
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 Using this keyword dramatically reduces the overall performance of Alliance
Access.
15 July 2011 335

Instance_type
This keyword represents the type of message instance.
The values are:
• Copy
• Notification
• Original
Last_operator_name
This keyword represents the username of the operator that last worked with the instance.
Live_mesg
This keyword represents the distinction between "live" or "test" messages. The value of the
keyword is either true or false.
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.
Message Identifier
This keyword represents the message identifier.
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.

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.
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
Network_priority
This keyword represents the priority of the message over the network.
The values are:
• System
• Urgent
• Normal
15 July 2011 337

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.
Priority
This keyword represents the priority of the message instance within Alliance Access. The values
are 9 (lowest priority) through 0 (highest priority).
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.
Related_TRN
This keyword represents the related Transaction Reference Number. For SWIFT messages, this
is located in field 21 of the message text.

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.
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.
Sender_reference
This keyword represents the message reference for messages that are entered by APPLI.
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)
15 July 2011 339

Status
The keyword indicates whether the message is live or completed.
Sub_format
This keyword indicates whether the message was input or output to SWIFTNet after it was
created.
The values are:
• Input
• Output
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.
Today
This keyword represents the date of routing.
The format is: DD/MM/YYYY. For example, 20/01/2011.
Warning Do not use the Today keyword in a conditional statement. It is reserved for use by
the system only.

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.
Unit_name
This keyword represents the name of the unit that owns the message instance.
Validation
This keyword represents the validation level that the message passed successfully.
The values are:
• Intermediate
• Maximum
• Minimum
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.
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

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.

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

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.

Configuring Message Delivery (Delivery Subsets)
To define a future delivery subset:

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

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.

For a description of the fields displayed in this tab, see "Future Subset Details - Part 2 Tab"
on page 351.
14. Select the Used check box.
selection.
For details on how to configure these options, see step 9.
16. In the Future Subsets menu, select Add.
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

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.
20. Select the Used check box.
selection.
For details on how to configure these options, see step 9.
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.

• 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

Example of Future Subset Details - Part 1 tab
Field descriptions
Destination (shown in the window title bar)
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.

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".

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.
15 July 2011 351

Field descriptions
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.
entered below. Message Categories are disabled if you selected System in the Priority field.
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.
Part 2 Branch Codes
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
the Field 13C box to enable this option.

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.

Field descriptions
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.
entered below. Message Categories are disabled if you selected System in the Priority field.
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.
Part 3 Branch Codes
alphanumeric characters).
15 July 2011 353

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
the field 13C box to enable this option.
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:

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.
25.4 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:
2. From the View menu, select Destination.

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 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.
25.5 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

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:
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.

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.
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. 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.
15 July 2011 357

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
:32A:980228USD100, the fields match the expected syntax.
:53B:SWIFT
:32A:980303NOK250,
:20:TRN The result is a fast template, because the syntax of field 32A
:32A:980228 does not match the expected syntax.
:53B:SWIFT
:32A:980303NOK250,
:20:TRN The result is a fast template, because the second occurrence of

:32A:980228USD100, 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,

:32A:980228USD100, but there is still a field 53C to try to match. That field is
incompatible with the expected syntax.
:53B:SWIFT
:53C:/SWIFT

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 sequence B
MF32F
MF87 A, B or D
MF34P
OF53A, B or D
MF57A, B or D
End of sequence B
Start of optional sequence C
MF32F MF87A, B or D
MF34R MF57A, B or D
End of sequence C
and the input template contains the following information:

:32F:<correct syntax>
:34R:<correct 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

assume that the input template contains the following information:

:30:<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>
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:

1. Start the Alliance Access servers in Operational Mode.
3. From the File menu, select Export Message Templates. The Export Message
Templates window appears.

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

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.

Increasing Message Throughput
To modify an event so that it is ignored (not journalised):

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.
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.
27.3 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).
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

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:

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.

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
15 July 2011 365


Part D - Appendices
Part D
Appendices
15 July 2011 367


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 For clarity, the 'R7.0_' prefix is omitted from the profile names in the headings of
the tables.
A.1 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

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.

• 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 LSO/RSO Super Super- Import Operator RMA

permissions Key visor Export 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 None - ✓ ✓ - - -
Checks
A.1.2 Application Interface Application

Entitlements and permissions within the Application Interface application
Entitlement Specific permissions Super Super- Import Operator Msg

Key visor Export Partner
Open Application None ✓ ✓ ✓ ✓ ✓
Abort Session Message Partner(s) None None - None -

(Allowed/Prohibited) prohibited prohibited prohibited
Add Exit Point None ✓ ✓ ✓ - -
Add Partner Local Authentication Key:
First part (Yes/No) Yes Yes Yes - -
Second part (Yes/No) Yes Yes Yes - -
Session Authentication Key:
Create Message Own destination None - - - None

(Allowed/Prohibited) prohibited prohibited
MT None - - - None
15 July 2011 371


CCY+[AMOUNT] None - - - None

Service $ identifier None - - - None

Dispose Message Bypass verify MT 999 - - - None

(Allowed/Prohibited) allowed prohibited
Bypass verify CCY None - - - None

Bypass auth. MT 999 - - - None

(Allowed/Prohibited) allowed prohibited
Bypass auth. CCY None - - - None

Bypass authorisation: None - - - None

Service $ identifier prohibited prohibited
(Allowed/Prohibited)
Enable Mess. Partner None ✓ ✓ - - -
Mod Exit Point None ✓ ✓ ✓ - -
Mod Partner Local Authentication Key:
Move to Routing Point None ✓ - - - ✓
Open/Print Exit Point Exit Points None None None None -

(Allowed/Prohibited) prohibited prohibited prohibited 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 None None None None -

Rem Exit Point None ✓ ✓ - - -
Rem Partner Local Authentication Key:
First part (Yes/No) Yes Yes - - -
Second part (Yes/No) Yes Yes - - -


First part (Yes/No) Yes Yes - - -
Second part (Yes/No) Yes Yes - - -
Run Session Message Partner(s) None None - None -

Start Session Message Partner(s) None None - None -

(Allowed/Prohibited) Prohibited prohibited prohibited
Stop Session Message Partner(s) None None - None -

A.1.3 Calendar Application

Entitlements and permissions within the Calendar application
Entitlement Specific permissions Super Supervisor

Key
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 Super Super- Import Operator

permissions Key visor Export
Open Application None ✓ ✓ ✓ ✓
Add Alias None ✓ ✓ - ✓
Add Correspondent None ✓ ✓ ✓ -
Add Country None ✓ ✓ - -
Add Currency None ✓ ✓ - -
Install Bankfile Store schedule (Yes/ Yes Yes - -

No)
Modify operating Yes Yes - -

mode (Yes/No)
Modify Alias None ✓ ✓ - ✓
15 July 2011 373

Entitlement Specific Super Super- Import Operator

Modify Corr Dets None ✓ ✓ ✓ ✓

(Correspondent
details)
Modify Country None ✓ ✓ - -
Modify Currency None ✓ ✓ - -
Open/Print Alias None ✓ ✓ - ✓
Open/Print Corr Dets None ✓ ✓ ✓ ✓

(Correspondent
details)
Open/Print Country None ✓ ✓ - ✓
Open/Print Currency None ✓ ✓ - ✓
Remove Alias None ✓ ✓ - -
Remove None ✓ ✓ - -
Correspondent
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 Supervisor

Key
Open Application None ✓ ✓ ✓
Archive Store schedule (Yes/No) - Yes Yes
Modify operating mode - Yes Yes

(Yes/No)
A.1.6 Message Approval Application

Entitlements and permissions within the Message Approval application
Entitlement Specific permissions Super Supervisor Msg

Key Entry
Approve Message Own destination 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 No

(Yes/No)
Auth. own entered Mesg Yes No No

(Yes/No)


Key Entry
Auth. own verified Mesg Yes No No

(Yes/No)
Group Authorise (Yes/No) Yes No No
CCY/Amount None prohibited None prohibited None prohibited

Swift FIN User MT None prohibited None prohibited None prohibited

Swift FIN System MT None prohibited None prohibited None prohibited

Swift APC System MT None prohibited None prohibited None prohibited

Service $ identifier None prohibited None prohibited None prohibited

Dispose Message Bypass Authorisation for None prohibited - None prohibited

CCY/Amount
Bypass Authorisation for None prohibited - 999 allowed

Swift FIN User MT
Route Message None ✓ - -
Treat Recovered Msg Own destination None prohibited None prohibited -

Group Authorise (Yes/No) Yes Yes -
A.1.7 Message Creation Application

Entitlements and permissions within the Message Creation application

Key Entry
Open Application None ✓ - ✓
Add/Mod/Rem Template None ✓ - -
Create Message List of Own-Destination None prohibited None prohibited None prohibited
Can create broadcasting Yes - No

(Yes/No)
CCY/Amount None prohibited - None prohibited

Swift FIN User MT None prohibited - None prohibited

Swift FIN System MT None prohibited - None prohibited

15 July 2011 375


Key Entry
Swift APC System MT None prohibited - None prohibited

Multiple Retrieval Allowed Yes - No

for SWIFTNet FIN System
Messages (Yes/No)
Multiple Retrieval Allowed Yes - No

for APC System Messages
(Yes/No)
SWIFTNet FINCopy Yes - No

Allowed (Yes/No)
Service $ identifier None prohibited - None prohibited

Dispose Message Bypass Verification CCY/ None prohibited - None prohibited

Amount
Bypass Authorisation None prohibited - None prohibited

CCY/Amount
Bypass Verification Swift None prohibited - 999 allowed

FIN User MT
Bypass Authorisation Swift None prohibited - 999 allowed

FIN User MT
Bypass Authorisation Swift None prohibited - None prohibited

FIN System MT
Bypass Authorisation Swift None prohibited - None prohibited

APC System MT
Bypass authorisation: None prohibited - None prohibited

service $ identifier
Route Message None ✓ - -
A.1.8 Message Modification Application

Entitlements and permissions within the Message Modification application
Entitlement Specific permissions Super Msg

Key Entry
Open Application None ✓ ✓
Bypass Security None ✓ -
Complete Message (that is, None ✓ ✓

discard the message)


Key Entry
Dispose Message Bypass Verification CCY/ None prohibited None prohibited

Amount
Bypass Authorisation CCY/ None prohibited None prohibited

Amount
Bypass Verification Swift FIN None prohibited 999 allowed

User MT
Bypass Authorisation Swift FIN None prohibited 999 allowed

User MT
Bypass Authorisation Swift FIN None prohibited None prohibited

System MT
Bypass Authorisation Swift None prohibited None prohibited

APC System MT
Bypass authorisation: service None prohibited None prohibited

$ identifier
Modify Message Own destination Allowed/ None prohibited None prohibited

Prohibited
Mod. in Text_modification Yes Yes

queue (Yes/No)
Mod. in Emission_security Yes No

queue (Yes/No)
Mod. in Transmission_modif Yes Yes

queue (Yes/No)
Mod. in Modif_after_recept Yes Yes

queue (Yes/No)
Mod. in Reception_security Yes No

queue (Yes/No)
CCY/Amount None prohibited None prohibited

Swift FIN User MT None prohibited None prohibited

Swift FIN System MT None prohibited None prohibited

Swift APC System MT None prohibited None prohibited

Multiple Retrieval Allowed for Yes Yes

FIN System Mesg (Yes/No)
Multiple Retrieval Allowed for Yes Yes

APC System Mesg (Yes/No)
15 July 2011 377


Key Entry
SWIFTNet FINCopy Allowed Yes Yes

(Yes/No)
Service $ identifier None prohibited None prohibited

Route Message None ✓ -
A.1.9 Message File Application

Entitlements and permissions within the Message File application
Entitlement Specific LSO/RSO Super Supervisor

permissions Key
Archive Store schedule (Yes/ - Yes Yes

No)
Modify operating - Yes Yes

mode (Yes/No)
Change priority None - ✓ ✓
Complete Instance None - ✓ ✓
Count Completely hide ✓ (No) ✓ (No) ✓ (No)

messages of other
units (Yes/No)
Move Instance None - ✓ ✓
Re-activate Instance None - ✓ ✓
Re-assign Instance None - ✓ ✓
Search Completely hide No No No

messages of other
units (Yes/No)
A.1.10 Monitoring Application

Entitlements and permissions within the Monitoring application
Entitlement Specific LSO/RSO Super Super- Operator

permissions Key visor
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 ✓ ✓ ✓ -

Entitlement Specific LSO/RSO Super Super- Operator

permissions Key visor
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 Super RMA_ RMA_

permissions Key Admin Oper
Accept Auth Destinations None prohibited None prohibited -

Services None prohibited None prohibited -

15 July 2011 379


Bypass Approval No No -
(Yes/No)
Answer Message Destinations None prohibited None prohibited None prohibited

Services None prohibited None prohibited None prohibited

App Granularity Dest None ✓ ✓ -
Approve Auth Destinations None prohibited None prohibited -


Approve own Actions No No -

(Yes/No)
Approve Create Yes Yes -

(Yes/No)
Approve Revoke Yes Yes -

(Yes/No)
Approve Accept Yes Yes -

(Yes/No)
Approve Reject Yes Yes -

(Yes/No)
Approve Delete Yes Yes -

(Yes/No)
Clean up Auth None ✓ ✓ -
Create Auth Destinations None prohibited - None prohibited

Services None prohibited - None prohibited

Bypass Approval No - No
(Yes/No)
Def Granularity Dest None ✓ ✓ -
Def Signing BIC T&T None ✓ ✓ -
Delete Auth Destinations None prohibited None prohibited -


(Yes/No)
Delete Query/Answer Destinations None prohibited None prohibited -




Export Auth Destinations None prohibited None prohibited -


Store Schedule Yes Yes -

(Yes/No)
Modify operating Yes Yes -

mode
(Yes/No)
Export on Change None ✓ ✓ -
Import Auth Destinations None prohibited None prohibited -


Store Schedule Yes Yes -

(Yes/No)
Modify operating Yes Yes -

mode
(Yes/No)
Mark Obsolete Auth(1) None ✓ ✓ -
Mod Signing BIC T&T Destinations Allowed/ None prohibited None prohibited -
Prohibited
Modify Auth Destinations None prohibited - None prohibited

Services None prohibited - None prohibited

Bypass Approval No - No
(Yes/No)
Open/Print Auth Det Destinations None prohibited None prohibited None prohibited

Query Message Destinations None prohibited None prohibited None prohibited


Reject Auth Destinations None prohibited None prohibited -

15 July 2011 381


(Yes/No)
Revoke Auth Destinations None prohibited None prohibited -


(Yes/No)
Treat Query/Answer Destinations None prohibited None prohibited None prohibited


(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 LSO/RSO Super Super- Import

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 - ✓ ✓ -

A.1.13 Security Definition Application

Entitlements and permissions within the Security Definition application
Entitlement Specific permissions LSO/RSO Super Supervisor Import

Key Export
Add Operator None ✓ ✓ ✓ ✓
Add Profile None ✓ ✓ ✓ ✓
Add Unit None - ✓ ✓ ✓
Approve LDAP Approve Left or ✓ - - -

Approve Right part
Approve Operator Approve Left or Right Left - - -

part (Left/Right)
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 None ✓ - - -

Password(1)
Enable Operator None ✓ ✓ ✓ -
Mod Component None ✓ ✓ ✓ -
Mod Operator None ✓ ✓ ✓ ✓
Mod Profile None ✓ ✓ ✓ ✓
Mod Security None ✓ - - -

Parameters(1)
Mod Unit None - ✓ ✓ ✓
Rem Operator None ✓ ✓ ✓ -
Rem Profile None ✓ ✓ ✓ -
Rem Unit None - ✓ ✓ -
Reset User None ✓ - - -

Password(1)
Reset Peer Officer None ✓ - - -

Password(1)
(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

A.1.14 SWIFT Interface Application

Entitlements and permissions within the SWIFT Interface application
Entitlement Specific permissions Super Super- Import Operator

Key visor Export
Add Action None ✓ ✓ ✓ -
Ena / Dis Auto Mode None ✓ ✓ ✓ -

(Enable/Disable )
Ena / Dis Re-Connect None ✓ - ✓ -

(Enable/Disable)
Login/Select None ✓ ✓ - ✓
Modify Action None ✓ ✓ ✓ -
Modify LT None ✓ ✓ ✓ -
Modify Subsets None ✓ ✓ ✓ -
Own Destination List List Own Destinations None None None None
Redefine Delivery None ✓ ✓ - -
Remove Action None ✓ ✓ ✓ -
A.1.15 SWIFT Support Application

Entitlements and permissions within the SWIFT Support application

Key visor Export
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 None ✓ ✓ - -

(Message Syntax
Table)
Install VAS None ✓ ✓ - -


Key visor Export
Manage ASP None ✓ ✓ - -
Modify Keyword None ✓ ✓ ✓ -
Modify LT None ✓ ✓ ✓ -
Modify VAS None ✓ - - -
Own Destination List Own Destinations None None None None

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 Supervisor Import Operator

Key Export
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

Entitlement Specific permissions Super Supervisor Import Operator

Key Export
Enable RProf None ✓ ✓ - -
Enable RProf Auto None ✓ - ✓ -
Modify EProf None ✓ ✓ ✓ -
Modify RProf None ✓ ✓ ✓ -
Open/Print EProf Services None None None None

Own Destinations None None None None

Open/Print IChan Own Destinations None None None None

Open/Print OChan Own Destinations None None None None

Open/Print RProf RT None ✓ ✓ ✓ ✓
Open/Print RProf SnF Own Destinations None None None None

Remove EProf None ✓ ✓ - -
Remove IChan None ✓ ✓ - -
Remove OChan None ✓ ✓ - -
Remove RProf None ✓ ✓ - -
RT File Get Request Service(s) None None - -

Request type(s) None
prohibited
Schedule EProf Add Action (Yes/No) Yes No Yes -
Modify Action (Yes/No) Yes No Yes -
Remove Action (Yes/ Yes No Yes -

No)
Schedule RProf Add Action (Yes/No) Yes No Yes -
Modify Action (Yes/No) Yes No Yes -
Remove Action (Yes/ Yes No Yes -

No)
A.1.17 SWIFTNet Support Application

Entitlements and permissions within the SWIFTNet Support application
Entitlement Specific permissions LSO RSO Super Super- Import

Key visor Export
SNL Handling Connection Handling Yes Yes Yes Yes Yes

(Yes/No)

Entitlement Specific permissions LSO RSO Super Super- Import

Key visor Export
First Part Local Yes No Yes Yes No

Authentication Key
(Yes/No)
Second Part Local No Yes Yes Yes No

Authentication Key
(Yes/No)
Reset Connection Yes Yes Yes Yes No

Status (Yes/No)
A.1.18 System Management Application

Entitlements and permissions within the System Management application

Key Export
Add Device None ✓ ✓ ✓ -
Add Dist. List None ✓ ✓ ✓ ✓
Add Queue None - ✓ ✓ ✓
Backup (Software, Store schedule (Yes/ No Yes Yes -

Data, and Archives) No)
Modify operating mode No Yes Yes -

(Yes/No)
Hold Queue None ✓ ✓ ✓ -
Manage Rec Backup(1) None ✓ ✓ ✓ -
Mod Config. Param. None ✓ ✓ ✓ ✓
Mod Device None ✓ ✓ ✓ -
Mod Dist. List None ✓ ✓ ✓ -

(Distribution list)
Mod Event Dist. None ✓ ✓ ✓ ✓

(Distribution)
Mod Queue None ✓ ✓ ✓ ✓
Release Queue None - ✓ ✓ -
Rem Device None ✓ ✓ ✓ -
Rem Dist. List None ✓ ✓ ✓ -

(distribution list)
Rem Queue None - ✓ ✓ -
Reset Event None ✓ ✓ ✓ -

Distribution
Restart SWIFTAlliance Store schedule No Yes Yes -

(Yes/No)
15 July 2011 387


Key Export
Restore (Data, and None - ✓ ✓ -

Archives)
Stop SWIFTAlliance Store schedule (Yes/ No Yes Yes -

No)

(Yes/No)
Stop/Start Component None ✓ ✓ ✓ -
(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).

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

Note 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.
B.2 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:

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.
B.3 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)

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.
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
15 July 2011 391

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

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

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

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
• Success: The message was added successfully onto the AI inbound queue.
• 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

• 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
• 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.
• 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

• Success: The message was successfully processed and is valid.

• Failure
• Discard
_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
_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
• Success
• Failure
• Discard
_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

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.
Assigned MPF: mpm

• Failure
• Discard
_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.
Assigned MPF: mpm

• Failure
• Discard
_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.
Assigned MPF: mpa
• 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.
_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
• 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

• 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 re-
authentication queue (_MP_mod_rec_secu).
• Invalid Certificate Policy ID:

• Invalid digest:
• Invalid Sign DN:

• Not Authorised by RMA: A valid enabled authorisation was found, but the message was not
permitted.

• Signature Auth. failure: The signature verification failed, this result can be applicable to the
MAC equivalent or PAC equivalent signature.
• 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
• 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

Acceptance criteria: Creator mpf must be _SI_system_msg.

Assigned MPF: _SI_system_msg
• 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
• Success. The alarm message can be successfully routed to the message addressee.
• 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
• Delivered
• Not delivered
• Delayed delivery.
• 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
• Delivered
• Not delivered
• Not matched
• Delayed delivery.

_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
• 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
result equal to "Failure".
15 July 2011 403

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.
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
input session uses the File Transfer connection method, for example, batch transfer of
messages using a DOS or UNIX file.
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
• 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.

FileActAcks
This is the queue of ACK notifications related to outgoing FileAct messages created by
input session uses the File Transfer connection method.
These notifications are created at the SWIFTNet outbound routing point and routed to this exit
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
input session uses the File Transfer connection method.
FileDeliveryNotifAck
• 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
• FileDeliveryNotifNak. Negative FileAct delivery notifications.

The MPF at this routing point is AI_to_APPLI. From this exit point, you can send the delivery
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
MPF associated with the SWIFTNet outbound queue (_SI_to_SWIFTNet) to return a processing
15 July 2011 405

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
The notifications are created at the SWIFTNet outbound routing point and routed to this exit
MPF associated with the SWIFTNet outbound queue (_SI_to_SWIFTNet) to return a processing
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
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
• MXDeliveryNotifAcks. MX notifications.
The MPF at this routing point is _AI_to_APPLI. From this exit point, you can send the delivery
XML.

MXDeliveryNotifNaks
• MXDeliveryNotifNaks. MX notifications.
The MPF at this routing point is _AI_to_APPLI. From this exit point, you can send the delivery
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

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.

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.


routed to the MX delivery ACK queues.
• "Nacked": The outgoing message was negatively acknowledged.

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

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 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.

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

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.

You can find examples of the DOS-PCC message format in files with the .dos extension in the
• 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.

DOS-PCC Input Message Format
DOS-PCC Input and Output Message Format
15 July 2011 413

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

MAC/PAC values
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
Signature element (as provided by SWIFTNet Link) that is relevant to the message, as follows:
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 PAC2-
equivalent is appended to the MAC-equivalent signature in one SIG trailer.
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

You can find examples of the RJE message format in files with the .rje extension in the
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

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

D.3 MERVA/2 Format

MAC/PAC values
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
Signature element (as provided by SWIFTNet Link) that is relevant to the message, as
follows:
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.
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 For notification instances, no Unique File Transfer Reference is included.
15 July 2011 417


You can find examples of the MERVA/2 message format in files with the .mv2 extension in the
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.

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: - User Format Services (UFS)

Sic
UNIX only: - User Format Services (UFS)

Other networks
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 The example shows only the more commonly used fields. It does not contain all
possible PDU fields available to the protocol.
15 July 2011 419

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.

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.
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

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.

15 July 2011 423

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.
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.

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.

You can find examples of the XML version 1 message format in files Samples_v1.tar.Z in the
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 byte-
order marker is not supported.
15 July 2011 425

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


Not present if LogicalReply is present.
( The Message. Message M M

Message
|
Report The Report. Report -- M

|
LogicalReply LogicalReply sent to MQSA. LogicalReply -- M

)
Message
MessageFormat The message format. String M M

• MX
MessageSubFormat The message sub-format. String M M

• Input
• Output
From: only Input is allowed.
Sender The address of the message sender AddressFullName M M

message sender (see "AddressFullName").
The first 8 characters of the X1 member
must match the institution of the
RequestorDN (case insensitive, see
"SWIFTNetRequestAttribute").
Receiver The address of the message receiver (see Address M M

Address).
LiveMessage Is it a live message or is it a test Boolean -- M

message?:
• true: message is Live
• false: test message (pilot)
MessageNature The message nature. String M M

• FinancialNature
• TextNature
• NetworkNature
• SecurityNature
• ServiceNature
15 July 2011 427


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 Any M M

Application Header(1) (if required) and the
Business Document. Both are described in
the documentation of the Solutions.
(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
OriginalMessage The Alliance Access instance type: Boolean -- O
• true: Original instance
• false: Copy instance
ModifyAllowed If set to true, then the message can be Boolean O --

modified using the Message Modification
application in Alliance Messenger(1)
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 Boolean O --

delete the message, if it is still in the
creation queue.
Default value: false
MinValidation Requested message validation level. String O --

• None
• Minimum
Extract routing keywords from message
text
• Intermediate
(same as minimum)
• Maximum
(same as minimum)


If specified, has precedence over the
Alliance Access configuration.
CBTPriority The Alliance Access message priority. Integer(0..9) O --

If not present, then it is determined by the
field NetworkPriority (see "MessageTPI").
DispositionState The requested message disposition state. String O --

The corresponding routing point name is
listed between parentheses.
• 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. FormatAttribute O O

Not currently used.
TargetApplication Specifies where the message has to be TargetApplication O --

created in Alliance Access.
Alliance Access Message Partner
configuration.
MessageOrigin The Alliance Access component that MessageOrigin -- O

created the message. See
"MessageOrigin".
CBTRoutingInfo The routing point the message instance String(1..20) -- O

was located on before emission to the
application.
MANRoutingCode Information to influence the routing in String(1..6) O O

Alliance Access. The code entered here is
visible through the routing keyword
"Routing_code".
15 July 2011 429

DuplEmission Indicates whether Alliance Access already Boolean -- O

attempted to send this message instance to
the application.
(1) The Alliance Workstation Message Modification application does not support editing MX messages.
NetworkAttribute
SWIFTNetRequestAttribute SWIFTNet request attributes. SWIFTNetRequest M M

Attribute
SWIFTNetResponseAttribu SWIFTNet response network attributes. SWIFTNetResponse -- O

te Attribute
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.
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, String(1..30) M O

the Message Identifier)
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 Boolean O --

requested.
Default value: as defined in the Alliance
Access emission profile configuration
NonRepType Non-repudiation processing information String -- O

(Type).
Possible Values are:
• SvcOpt
• SvcMand
NonRepWarning Non-repudiation processing information String -- O

(Warning)

SwiftRef The reference generated by the central String -- O

SWIFT infrastructure.
Always present for output messages,
Transmission Reports with
NetworkDeliveryStatus NetworkAcked and
Delivery Reports.
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.
SwiftRequestRef The reference generated by the emitting String -- O

SWIFTNet Link.
Always present for output messages,
Transmission Reports with
NetworkDeliveryStatus NetworkAcked and
Delivery Reports.
SNLid-YYYY-MM-
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 String -- O

Access (for messages sent) or by the
correspondent application (for messages
received).
SNLEndPoint The SWIFTNet Link endpoint. String -- O

Real-time messages only.
SnFQueueName The store-and-forward queue name. String -- O
SnFInputTime SWIFTNet storage location and time of a String -- O

store-and-forward request (UTC).
Format:
nnnn:YYYY-MM-DDTHH:MM:SS
Where nnnn is the SWIFT internal storage
identifier.
SnFPDMHistory Duplication history details. Any (1) -- O

Output messages only.
ValidationDescriptor MVal processing result. Any (2) -- O
AuthResult The authentication result. String -- O
15 July 2011 431


• Success
• Bypassed
• Failed
AuthValue The authentication value. Any (2) -- O
(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
ResponderDN The responder DN. String -- O
NonRepType Non-repudiation processing information String -- O

(Type).
Possible Values are:
• SvcOpt
• SvcMand
NonRepWarning Non-repudiation processing information String -- O

(Warning)
ResponseRef The reference generated by the central String -- O

SWIFT infrastructure. For format
information, see SwiftRef in
"SWIFTNetRequestAttribute".
SwiftResponseRef The reference generated by the emitting String -- O

SWIFTNet Link.
For format information, see
SwiftRequestRef in
"SWIFTNetRequestAttribute".
CBTReference The reference generated by the responding String -- O

application.
DuplCreation Indicates whether the response is a String -- O

possible duplicate.
• None
• PDE


(1)
ValidationDescriptor MVal processing result of the response. Any -- O
AuthResult The authentication result of the response. String -- O

• Success
• Bypassed
• Failed
AuthValue The response authentication value. Any (1) -- O

(1) These fields contain SWIFTNet data elements that are provided for purposes of completeness. Further processing
of these elements is not required.
SecurityAttribute
SWIFTNetSecurityAttribute SWIFTNet security attributes. SWIFTNetSecurity M M

Attribute
SWIFTNetSecurityAttribute
SigningRequired Indicates whether signing of the message Boolean O --

is required upon emission.
If specified, it overrides the Alliance Access
emission profile configuration.
SignerDN The Signer DN String -- O
MessageTPI
NetworkDelivNotify Indicates whether a positive delivery Boolean O --

notification is requested.
Default value: false
Network The network over which the message was String -- M

transmitted.
• ApplicationNetwork
• SwiftNetNetwork
• OtherNetwork
NetworkPriority The Network priority. String O O
15 July 2011 433


• 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 String -- O

marked as duplicate by the sender (PDE),
or if the store-and-forward central system
attempted to deliver the message multiple
times (PDM).
• None
• PDM
• PDE
• PDE_PDM
MessageSRI
UserReference The Message User Reference. This String(1..30) O O

corresponds to the SWIFTNet RequestRef
(part of the InterAct RequestHeader)
UserPDE The application indicates whether the Boolean O --

message is a possible duplicate.
Report
Addressee The address of the receiver of the original AddressFullName -- M

instance (see "AddressFullName").
OrigMessageFields The level of detail that Alliance Access String -- M

provides about the original message, as
defined in the Alliance Access
configuration.
• NoOriginal


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 -- O

Not present if OrigMessageFields contains
NoOriginal.
ReportLPI The report Local Processing Information. ReportLPI -- M
( Transmission report. TransmissionReport -- M

TransmissionReport
|
DeliveryReport Delivery report. DeliveryReport -- M

) Indicates whether the message has been
received by the correspondent or not.
ReportLPI
OrigSenderReference The Original Sender reference. String(1..40) -- O
MessageOrigin The Alliance Access component that MessageOrigin -- M

created the message. See
"MessageOrigin"
Modified Indicates whether the message has been Boolean -- O

modified within Alliance Access.
OriginalRelatedMessage Indicates whether this report is about an Boolean -- O

Original (true) or a Copy instance (false) of
the message.
ReportingApplication The Alliance Access application that String -- M

generated the report.
BackToNonOriginator Indicates whether the report is sent back to Boolean -- O

the entity that created the message in
Alliance Access.
15 July 2011 435


DuplEmission Indicates whether Alliance Access already Boolean -- O

attempted to send this message instance to
the application.
TransmissionReport

transmitted.
• SwiftNetNetwork
• OtherNetwork
NetworkAttribute The network attributes. NetworkAttribute -- M
NetworkDeliveryStatus The network delivery status. String -- M

• 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 The list of interventions. Intervention [1..N] -- M

DeliveryReport

transmitted.
• SwiftNetNetwork
NetworkAttribute The network attributes. NetworkAttribute -- M
ReceiverDeliveryStatus The delivery notification status. String -- M

• RcvUnknown
• RcvOverdue
• RcvDelivered
• RcvAborted
• RcvDelayedNak
• RcvAcked
• RcvNacked
• RcvTruncated
Interventions The list of interventions Intervention [1..N] -- M
Intervention
IntvCategory Intervention category. String -- M

• TransmissionReport
• DeliveryReport
• TransmissionResponse: can be present

in TransmissionReport
CreationTime The intervention creation time. String -- M

Format:
YYMMDDHHMMSS
ApplicationOrigin The application that created the String -- M

intervention.
OperatorOrigin The name of operator that triggered the String -- M

intervention creation.
15 July 2011 437


(1)
Text The intervention text. Any -- 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 Real-
Time".
LogicalReply
This element is used exclusively by MQSA.
SenderReference Contains the UUMID of the message if it String(1..50) -- O

has been added to the Alliance Access
database. Not present if the message has
not been added.
SuccessIndication Indicates the result of the processing of the Boolean -- M

original message by MQSA:
• true: if the message was added

successfully by MQSA
• false: if an error occurred during the

processing of the message by MQSA
ErrorText Text associated with the error. String -- O

Only present if SuccessIndication is false.
Address
( The correspondent nickname. String(1..32) M --

Nickname Currently not applicable to MQSA.
|
FullName The correspondent full name. AddressFullName M M

)
AddressFullName
X1 The correspondent X1 part. String(11..11) M M

The institution BIC11.
X2 The correspondent X2 part. String(1..20) O O

Present if correspondent type is:
• Department
• Application
• Individual


Present if correspondent type is:
• Application
contains routing information
• Individual
contains the last name

Present if correspondent type is Individual
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
TargetApplication
This element is not used by MQSA.
TargetApplicationRule The routing function to be performed on the String M --

message by Alliance Access.
• 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. String(1..20) O --

Mandatory if TargetRoutingRule is
"RoutingPoint".
MessageOrigin
CBTApplication The Alliance Access application that String -- M

created the message.
• ApplicationInterface
• SwiftnetInterface
15 July 2011 439


• MessageEntry
• MessengerAdapter
• Other
MessagePartner The Message Partner that created the String -- O

message.
Present if CBTApplication is
ApplicationInterface.
SessionNr The session number. Integer -- O

Present if CBTApplication is
ApplicationInterface.
SeqNr The sequence number. Integer -- O

Mandatory when MessagePartner is
present.
FormatAttribute
FormatAttributeMX MX format attributes FormatAttributeMX M M
FormatAttributeMX
None Reserved for future use.
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.

AckNack
PseudoAckNack Alliance Access-generated Pseudo SWIFT String -- M

Acknowledgement (for more information
see "Creation of an Emission Appendix").
SwGbl:Status Optional SWIFTNet report status. SwGbl:Status -- O
SwGbl:Status
SwGbl:StatusAttributes Report status of top-level processing of SwGbl:StatusAttributes -- M

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).
SwGbl:StatusAttributes
SwGbl:Severity Possible values are: String -- M
• Fatal
• Transient
• Logic
• Success
• Warning
SwGbl:Code Status code. The list of error codes is String -- M

available in SWIFTNet Link Error Codes
(part of the SWIFTNet Link documentation
set).
SwGbl:Parameter Content depends on the error. Any [0..N] -- O
SwGbl:Text Textual description. No processing, except String -- O

display/print for information, must be
performed on this element.
SwGbl:Action Proposed corrective action. String -- O
SwGbl:Details Lower level detailed report. SwGbl:Details [0..N] -- O
SwGbl:Details
SwGbl:Code Status code. String -- M
SwGbl:Text Textual description. String -- O
An example of the SwGbl:Status can be found in the TranmissionReport samples listed in "File
Transfer Examples".
15 July 2011 441

Sw:SnFPDMHistory
Sw:SnFPDMHistory In case of previous delivery attempts, gives Sw:SnFDeliveryHistory -- M

the delivery attempt history.
Sw:SnFDeliveryHistory
Sw:SnFDeliveryInfo Message delivery information. Sw:SnFDeliveryInfo -- O

In case of disaster take-over (SWIFT side), [0..N]
all messages present in the queue at the
moment of the disaster are flagged for
possible duplicate delivery, but without
delivery information.
Sw:SnFDeliveryInfo
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 String -- O

the message was delivered.
Format:
<queue>:(d|p):<6 digit session
number>
SwInt:SNLId SNL ID of the physical SWIFTNet Link String -- O

where message was delivered.
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>

Sw:NotifySnFRequestHandle
Sw:SnFRef Store-and-forward message reference of String -- M

the notification.
Contains the SwiftRef of the original
message (see
Sw:SnFRefType Type of message for which this notification String -- M

is provided.
Possible values:
• InterAct
Sw:AcceptStatus Type of store-and-forward notification String -- M

Possible values:
• Accepted: message accepted by the

receiver
• Rejected: message rejected by the

receiver
• Failed: SWIFT failed to deliver the

message
Sw:AckSwiftTime The SWIFT acceptance time of the request String -- M

("Accepted", "Rejected") or generation time
of the delivery notification request ("Failed")
in UTC.
Format:
Sw:AckDescription Provides information about the String -- O

acknowledgement.
Free text.
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

Sw:AckInfo Provides information about the String -- O

acknowledgement.
Structured data that the client can analyse.
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
SwInt:ValResult Indicates the result of validation. String -- M

Possible values:
• Success
• Warning
• Fatal (not currently used)
SwInt:ValStatus This contains the details of error(s) found. SwGbl:Status -- O

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:Severity>Warning</SwGbl:Severity>
<SwGbl:Code></SwGbl:Code>
<SwGbl:Text></SwGbl:Text>
</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.

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

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.

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-and-
forward 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

• 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:
– 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

<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: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>
<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: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>
15 July 2011 449

<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: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: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)

<Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv10609141402
</Saa:SenderReference>
<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:ReportLPI>
<Saa:MessageOrigin>
</Saa:ReportLPI>

<Saa:SWIFTNetResponseAttribute/>
<Saa:NetworkDeliveryStatus>NetworkNacked</Saa:NetworkDeliveryStatus>
<Saa:Interventions>
<Saa:Intervention>
<Saa:Text>
<AckNack>
{451:1}{405:T02}{311:NAK Sw.WFE.eMVALError}{108:Sample-XMLv1-0609141402}}</
PseudoAckNack>
<SwGbl:Status>
<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:Text>Execute Request failed in WFE </SwGbl:Text>
</SwGbl:Details>
<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>
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>
15 July 2011 451

016.001.02[1]/IndvOrdrDtlsRpt1[1]/Sts[1]</SwGbl:Parameter>
$setr.016.001.02}Sts"</SwGbl:Text>
016.001.02[1]/IndvOrdrDtlsRpt1[1]/OrdrRef[1]</SwGbl:Parameter>
$setr.016.001.02}OrdrRef"</SwGbl:Text>
016.001.02[1]</SwGbl:Parameter>
<SwGbl:Text>unexpected end of content</SwGbl:Text>
</SwGbl:Status>
</AckNack>
</Saa:Text>
</Saa:Intervention>
</Saa:Report>
</Saa:DataPDU>
Transmission Report (Ack) including the original message

<Saa:SenderReference>ISAADBEBBXXX016Sample-XMLv1-0609141402
<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:OrigMessageFields>Full</Saa:OrigMessageFields>
<Saa:OrigMessage>
<Saa:Sender>
</Saa:Sender>
<Saa:Receiver>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:LiveMessage>true</Saa:LiveMessage>
<Saa:MessageLPI>
<Saa:OriginalMessage>false</Saa:OriginalMessage>

<Saa:CBTReference>a7e67cde-e52a-4b0c-a3ad-af3f97dbaa6e</
Saa:CBTReference>
<Saa:SignerDN>cn=rma2,o=saadbebb,o=swift</Saa:SignerDN>
<Saa:MessageOrigin>
<Saa:CBTRoutingInfo>MXAck</Saa:CBTRoutingInfo>
</Saa:MessageLPI>
<Saa:MessageTPI>
</Saa:MessageTPI>
<Saa:MessageSRI>
</Saa:MessageSRI>
<Saa:MessageText>
<CrDate>2006-09-14T02:02:11.414</CrDate>
</AppHdr>
<setr.016.001.02>
<RltdRef>
<Ref>Ref123-1</Ref>
</RltdRef>
<IndvOrdrDtlsRpt>
<Sts>PACK</Sts>
</IndvOrdrDtlsRpt>
</setr.016.001.02>
</Document>
</Saa:MessageText>
</Saa:OrigMessage>
<Saa:ReportLPI>
<Saa:MessageOrigin>
</Saa:ReportLPI>
15 July 2011 453

<Saa:Interventions>
<Saa:Intervention>
<Saa:Text>
<AckNack>
</AckNack>
</Saa:Text>
</Saa:Intervention>
</Saa:Report>
</Saa:DataPDU>
Delivery Report sent by Alliance Access to the application

<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:ReportLPI>
<Saa:MessageOrigin>
<Saa:ReportingApplication>Traffic Recon</Saa:ReportingApplication>
</Saa:ReportLPI>
<Saa:DeliveryReport>

<Saa:ReceiverDeliveryStatus>RcvDelivered</Saa:ReceiverDeliveryStatus>
<Saa:Interventions>
<Saa:Intervention>
<Saa:IntvCategory>DeliveryReport</Saa:IntvCategory>
<Saa:ApplicationOrigin>TRS</Saa:ApplicationOrigin>
<Saa:Text>
</Saa:Text>
</Saa:Intervention>
</Saa:DeliveryReport>
</Saa:Report>
</Saa:DataPDU>
Message sent by Alliance Access to the application

<Saa:SenderReference>OSAADBEBBXXX016Sample-XMLv1-0609141402
<Saa:Message>
<Saa:MessageSubFormat>Output</Saa:MessageSubFormat>
<Saa:Sender>
</Saa:Sender>
<Saa:Receiver>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:MessageLPI>
<Saa:OriginalMessage>true</Saa:OriginalMessage>
15 July 2011 455

<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:SWIFTNetResponseAttribute/>
<Saa:MessageOrigin>
<Saa:CBTApplication>SwiftnetInterface</Saa:CBTApplication>
<Saa:CBTRoutingInfo>MXRecv</Saa:CBTRoutingInfo>
</Saa:MessageLPI>
<Saa:MessageTPI>
<Saa:DuplCreation>PDE</Saa:DuplCreation>
</Saa:MessageTPI>
<Saa:MessageSRI>
</Saa:MessageSRI>
<Saa:MessageText>
<CrDate>2006-09-14T02:02:11.414</CrDate>
</AppHdr>
<setr.016.001.02>
<RltdRef>

<Ref>Ref123-1</Ref>
</RltdRef>
<IndvOrdrDtlsRpt>
<Sts>PACK</Sts>
</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:Message>
<Saa:Sender>
<Saa:X1>SAASBEBBXXX</Saa:X1>
</Saa:Sender>
<Saa:Receiver>
<Saa:FullName>
<Saa:X1>SAATBEBBXXX</Saa:X1>
</Saa:FullName>
</Saa:Receiver>
<Saa:MessageLPI>
<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:MessageLPI>
<Saa:MessageTPI>
</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

</Saa:MessageText>
</Saa:Message>
</Saa:DataPDU>
Transmission Report sent by Alliance Access to the application

<Saa:SenderReference>ISAATBEBBXXXMX REF-1-0609181711</Saa:SenderReference>
<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:ReportLPI>
<Saa:MessageOrigin>
<Saa:MessagePartner>MXFileInput</Saa:MessagePartner>
</Saa:ReportLPI>
<Saa:CBTReference>b12ba774-c3bf-47df-9e8a-924282c3235c</Saa:CBTReference>
<Saa:SwiftResponseRef>SNL00229-2006-09-18T15:12:41.5304.000011Z
<Saa:AuthValue>
kM4MjINCkVudHJ1c3RGaWxlLVZlcnNpb246IDIuMA0KT3JpZ2luYXRvci1ETjogY249cm1hNCxvPXN
hYXRiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDE5Mzg1MjINCk1JQy1JbmZvOiBTSEExLCBSU0EsD
QogVmFTNlpqMC9rYnQrZVF0dHRhNmQvcnpPdVhmL3prc1NTeXBSc1RGWUxQOHAzazFLSDFOVnZacGF
XWDhoVTY4bg0KIFo4a1h3a2g1Q3VYNFgvenNQZUdtS1pKWTBvWVZXM3c1cmdyYm5YMjVzQml5cURVc
y9MYlRxci8wV0dIaUI4ZWQNCiBzR0xRenFRNFh3VmxGRmlUN0FxWjErUHovQURmQlFmemd2N1JibWp
HWWxrTk54NVNpMUk4ajZ5VjU3bnBpSCtVDQogM21MWmhuUFNvcThZbEZIVEhzS3dCOExWNko0U25yb
zd1NWRVc2ZjZUVqbUVZeERGK21qaXlwSytXaUdTVWZlWg0KIE01R21nUk9rb0k5N2k4STZ4d2J4QUd
lL3UrZ0M4enJ5NUd1SHVtTElXcHpRUEsvejVGWmRSTEpqajNGaXJKZW0NCiAyU2pucXo5OXNEWUF1b
WJBT0E5N25RPT0NCg==</SwSec:CipherKey>
<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>

</Saa:AuthValue>
<Saa:Interventions>
<Saa:Intervention>
<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:Text>
<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"
<Doc:returnaccount>
<Doc:QryRef>
</Doc:QryRef>
<Doc:RtrRef>
<Doc:Ref>RS01</Doc:Ref>
</Doc:RtrRef>
<Doc:Accts>
<Doc:AcctRpt>
<Doc:AcctId>
</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:Report>
</Saa:DataPDU>
15 July 2011 459

D.5.1.5 MQSA Examples
Introduction
The following sections show DataPDU examples for:
• Store-and-forward
– 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
– 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

<Saa:Message>
<Saa:Sender>
</Saa:Sender>
<Saa:Receiver>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:MessageLPI>
<Saa:NRIndicator>true</Saa:NRIndicator>
<Saa:SigningRequired>true</Saa:SigningRequired>
</Saa:MessageLPI>
<Saa:MessageTPI>

<Saa:NetworkDelivNotify>true</Saa:NetworkDelivNotify>
</Saa:MessageTPI>
<Saa:MessageSRI>
</Saa:MessageSRI>
<Saa:MessageText>
<CrDate>2006-09-14T02:02:11.414</CrDate>
</AppHdr>
<setr.016.001.02>
<RltdRef>
<Ref>Ref123-1</Ref>
</RltdRef>
<IndvOrdrDtlsRpt>
<Sts>PACK</Sts>
</IndvOrdrDtlsRpt>
</setr.016.001.02>
</Document>
</Saa:MessageText>
</Saa:Message>
</Saa:DataPDU>
Logical reply sent by MQSA to the application

<Saa:LogicalReply>
<Saa:SuccessIndication>true</Saa:SuccessIndication>
</Saa:LogicalReply>
</Saa:DataPDU>
Transmission Report sent by MQSA to the application (Ack)

<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:ReportLPI>
<Saa:OrigSenderReference>QU1RIFFNLkJFV1gxMjQgIIO0D0UgAA0B
</Saa:OrigSenderReference>
<Saa:MessageOrigin>
<Saa:CBTApplication>Other</Saa:CBTApplication>
<Saa:DuplEmission>false</Saa:DuplEmission>
</Saa:ReportLPI>
15 July 2011 461

<Saa:CBTReference>39d39f5a-fc26-4e5d-92f8-3bb42f4352f6</Saa:CBTReference>
<Saa:SWIFTNetResponseAttribute />
<Saa:Interventions>
<Saa:Intervention>
<Saa:Text>
<AckNack>
</AckNack>
</Saa:Text>
</Saa:Intervention>
</Saa:Report>
</Saa:DataPDU>
Transmission Report sent by Alliance Access to the application (Nack)

<Saa:SenderReference>ISAAIBEBBXXX016Sample-XMLv1-0609141402
<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:ReportLPI>
<Saa:OrigSenderReference>QU1RIFFNLk1YUyAgICAgIHTRLEUgACIC
<Saa:MessageOrigin>
</Saa:ReportLPI>
<Saa:CBTReference>0201e4e5-c347-4ed3-a96a-2c0eab280749</Saa:CBTReference>

<Saa:NetworkDeliveryStatus>NetworkNacked</Saa:NetworkDeliveryStatus>
<Saa:Interventions>
<Saa:Intervention>
<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: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:Text>Execute Request failed in WFE , MVAL</SwGbl:Text>
</SwGbl:Details>
<SwGbl:Details>
<SwGbl:Text>Execute Request failed in WFE</SwGbl:Text>
</SwGbl:Details>
<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>
016.001.02[1]/IndvOrdrDtlsRpt1[1]</SwGbl:Parameter>
$setr.016.001.02}IndvOrdrDtlsRpt1"</SwGbl:Text>
016.001.02[1]/IndvOrdrDtlsRpt1[1]/Sts[1]</SwGbl:Parameter>
$setr.016.001.02}Sts"</SwGbl:Text>
15 July 2011 463

016.001.02[1]/IndvOrdrDtlsRpt1[1]/OrdrRef[1]</SwGbl:Parameter>
$setr.016.001.02}OrdrRef"</SwGbl:Text>
<SwGbl:Parameter>SwInt:RequestPayload//Document[1]/setr.016.001.02[1]
</SwGbl:Parameter>
<SwGbl:Text>unexpected end of content</SwGbl:Text>
</SwGbl:Status>
</AckNack>
</Saa:Text>
</Saa:Intervention>
</Saa:Report>
</Saa:DataPDU>
Transmission Report (Ack) including the original message

<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:OrigMessageFields>Full</Saa:OrigMessageFields>
<Saa:OrigMessage>
<Saa:Sender>
</Saa:Sender>
<Saa:Receiver>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:MessageLPI>
<Saa:OriginalMessage>false</Saa:OriginalMessage>
<Saa:CBTReference>0aad3ea0-2d15-4d2d-8ce5-e6dfe47cdb4c
</Saa:CBTReference>

<Saa:MessageOrigin>
<Saa:CBTRoutingInfo>SMQS_To_MQSeries</Saa:CBTRoutingInfo>
</Saa:MessageLPI>
<Saa:MessageTPI>
</Saa:MessageTPI>
<Saa:MessageSRI>
</Saa:MessageSRI>
<Saa:MessageText>
<CrDate>2006-09-14T02:02:11.414</CrDate>
</AppHdr>
<setr.016.001.02>
<RltdRef>
<Ref>Ref123-1</Ref>
</RltdRef>
<IndvOrdrDtlsRpt>
<Sts>PACK</Sts>
</IndvOrdrDtlsRpt>
</setr.016.001.02>
</Document>
</Saa:MessageText>
</Saa:OrigMessage>
<Saa:ReportLPI>
<Saa:OrigSenderReference>QU1RIFFNLk1YUyAgICAgII7oNUUgAF8E
<Saa:MessageOrigin>
</Saa:ReportLPI>
<Saa:CBTReference>0aad3ea0-2d15-4d2d-8ce5-e6dfe47cdb4c</Saa:CBTReference>
15 July 2011 465

<Saa:Interventions>
<Saa:Intervention>
<Saa:Text>
<AckNack>
</AckNack>
</Saa:Text>
</Saa:Intervention>
</Saa:Report>
</Saa:DataPDU>
Delivery Report sent by MQSA to the application

<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:ReportLPI>
<Saa:OrigSenderReference>QU1RIFFNLkJFV1gxMjQgIIO0D0UgAA0B
<Saa:MessageOrigin>
<Saa:ReportingApplication>Traffic Recon</Saa:ReportingApplication>
</Saa:ReportLPI>
<Saa:CBTReference>39d39f5a-fc26-4e5d-92f8-3bb42f4352f6</Saa:CBTReference>
<Saa:ReceiverDeliveryStatus>RcvDelivered</Saa:ReceiverDeliveryStatus>
<Saa:Interventions>
<Saa:Intervention>
<Saa:ApplicationOrigin>TRS</Saa:ApplicationOrigin>

<Saa:Text>
</Saa:Text>
</Saa:Intervention>
</Saa:Report>
</Saa:DataPDU>
Message sent by MQSA to the application

<Saa:SenderReference>OSAADBEBBXXX016Sample-XMLv1-0609141402
<Saa:Message>
<Saa:MessageSubFormat>Output</Saa:MessageSubFormat>
<Saa:Sender>
</Saa:Sender>
<Saa:Receiver>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:MessageLPI>
<Saa:OriginalMessage>true</Saa:OriginalMessage>
<Saa:CBTReference>79793722-19ac-4d6d-ad7e-a755349285ed</Saa:CBTReference>
<Saa:SNLEndPoint>sni_bewx124</Saa:SNLEndPoint>
<Saa:SnFQueueName>saadbebb_ifia</Saa:SnFQueueName>
<SwInt:ValResult>Success</SwInt:ValResult>
<Saa:AuthValue>
hYWRiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDc3ODU1NjYNCk1JQy1JbmZvOiBTSEExLCBSU0EsD
QogdUlTY2tYSkV1akFUQSt5bWFnaWJRU1I3b3B5Q3JheGV0L0ExZ2QzRy9mQkdyT0JZZmc1LzZIbzY
4S1hjdjFyRg0KIDQ5aHgxWWRWeDlyMElLMHZld2xHRnBVRUErdzhUcktzMG95QTFDbXd3am5iR1I5T
U92aWtGK01hNTQ2N3dXSHMNCiAxZU5Odk5zY0tNVHYyb2grU0RrcW9xS1hUUy8zQXpNNFphL2NCR25
PYUN2MEFocXFaQUFTazFneTE3c3dZMURlDQogNzhYYi9tdnMvRVZBT1o0RnY4MUhzWWhnM2lwNHRUO
EVlYnVNdFpvZDMycVkwemFLVVMrcUtGL2VwVjRQM2syMA0KIGMvaWJJc3ZKc1pCTTlQbzAyT1JyNXB
15 July 2011 467

sS1p1elVsS2tYcWhyZ1J6V0g1UEJoNEdjd0hqa0JFTTQ4dXVOQS96bUgNCiBCRnZSc0Q1ZVBuY0lsN
nM2ZHgwOXZnPT0NCg==</SwSec:CipherKey>
<SwSec:MemberRef>RequestDescriptor.SwiftRequestRef</SwSec:MemberRef>
<SwSec:SignDN>cn=rma2,o=saadbebb,o=swift</SwSec:SignDN>
</Saa:AuthValue>
<Saa:MessageOrigin>
<Saa:CBTApplication>SwiftnetInterface</Saa:CBTApplication>
<Saa:CBTRoutingInfo>SMQS_To_MQSeries</Saa:CBTRoutingInfo>
</Saa:MessageLPI>
<Saa:MessageTPI>
<Saa:DuplCreation>PDE</Saa:DuplCreation>
</Saa:MessageTPI>
<Saa:MessageSRI>
</Saa:MessageSRI>
<Saa:MessageText>
<CrDate>2006-09-14T02:02:11.414</CrDate>
</AppHdr>
<setr.016.001.02>
<RltdRef>
<Ref>Ref123-1</Ref>
</RltdRef>
<IndvOrdrDtlsRpt>
<Sts>PACK</Sts>
</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

<Saa:Message>
<Saa:Sender>

</Saa:Sender>
<Saa:Receiver>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:MessageLPI>
</Saa:MessageLPI>
<Saa:MessageTPI>
</Saa:MessageTPI>
<Saa:MessageSRI>
<Saa:UserReference>REF-1-0609181711</Saa:UserReference>
</Saa:MessageSRI>
<Saa:MessageText>
<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"
<Doc:getaccount>
<Doc:NstrAcctSchCrit>
<Doc:AcctId>
</Doc:AcctId>
<Doc:BalTp>AVLB</Doc:BalTp>
</Doc:NstrAcctSchCrit>
<Doc:QryPrcg>
<Doc:QryRef>
</Doc:QryRef>
</Doc:QryPrcg>
</Doc:getaccount>
</Doc:Document>
</Saa:MessageText>
</Saa:Message>
</Saa:DataPDU>
Logical reply sent by MQSA to the application

<Saa:LogicalReply>
<Saa:SuccessIndication>true</Saa:SuccessIndication>
</Saa:LogicalReply>
</Saa:DataPDU>
15 July 2011 469

Transmission Report sent by MQSA to the application

<Saa:Report>
<Saa:Addressee>
</Saa:Addressee>
<Saa:ReportLPI>
<Saa:OrigSenderReference>QU1RIFFNLkJFV1gxMjQgIH1WEUUgAAYC
<Saa:MessageOrigin>
</Saa:ReportLPI>
<Saa:CBTReference>9c2392bf-63d9-4a1c-bd27-a7c9d0c1b1b1</Saa:CBTReference>
<Saa:SwiftResponseRef>SNL00229-2006-09-20T15:03:31.5004.000005Z
<Saa:AuthValue>
kM4MjINCkVudHJ1c3RGaWxlLVZlcnNpb246IDIuMA0KT3JpZ2luYXRvci1ETjogY249cm1hNCxvPXN
hYXRiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDE5Mzg1MjINCk1JQy1JbmZvOiBTSEExLCBSU0EsD
QogZEF4b3VROFRFbldNNW03T2VOczZDdC8vTjFzOU9tUlo0cTFPdWI4ZnppT2xIQS95RDJhc2h5L2l
KU2VOcjBuYg0KIHpJUnV5M09LczJ1TUlxT2p3MnVKSEZvb0hKYmtQTUdPOGtIZG91clo4K0tVeGFHM
E5QSWtCTVJKYlZ0alRVdGgNCiBVcEw1TUJlSE5wcGtuN09VY2FUenFMT1ZQSnZ4Z2NrRUt4d25CNzd
5THRuay83YlRMVFhRR3FOVks2N0ROVS9rDQogcHZWZlUwWGxxNVVQWGoxMTVvWndxUS9HVzVHcGMxb
1hBYXpWdVJMTTFpa054UHRXejg0Sm9iT0FTVlR1VjFQYw0KIG9nNmRmUkRySGtSZWt2elh1V0pzazR
sQjFiWGYrOVpCWTF0aWNIUCtiaTd2akV5bDZ5Mk1Ca1dWWXVGVzJ4TWsNCiBjMTEzam5EQjhad255T
2kzMU5jV3ZBPT0NCg==</SwSec:CipherKey>
<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>
</Saa:AuthValue>

<Saa:Interventions>
<Saa:Intervention>
<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:Text>
<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"
<Doc:returnaccount>
<Doc:QryRef>
</Doc:QryRef>
<Doc:RtrRef>
<Doc:Ref>RS01</Doc:Ref>
</Doc:RtrRef>
<Doc:Accts>
<Doc:AcctRpt>
<Doc:AcctId>
</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: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


You can find examples of the XML version 1 message format in files Samples_v2.tar.Z in the
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.

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
• DeliveryReport
• MessageStatus
New Auxiliary type SAAInfo

An auxiliary type, SAAInfo, has been added for use with the MQ Host Adapter:
InstanceName The instance name of the Alliance Access String O M

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
UserName The OS user that runs the Alliance Access String O M

server.
Unit The Alliance Access Unit to which the String O M

message belongs.
Changes to data sub-element of InterfaceInfo
RoutingCode Information which is used for routing String O O

inAlliance Access. The code entered here
is visible through the routing keyword
'Routing_code' (see "RoutingInstruction").
15 July 2011 473


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
RequestType Contains the Request Type of the String O O

message. If not present, then the request
type is assumed to be the same as the
message identifier
Overview
This section provides a brief overview of the changes to the data elements in revision 2.0.2.

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 Real-
Time 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 sub-
elements 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.

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
Name Name of the attribute associated to the String M M

payload of the SWIFTNet request, or
response.
Value Value of the attribute associated to the String M M

payload of the SWIFTNet request, or
response.
New Auxiliary type PayloadAttributeList
PayloadAttribute The list of occurrences of the name, and PayloadAttribute [1..N] O O

value of an attribute.
New Auxiliary type Product
VendorName Name of the vendor of the back-office String O O

application.
ProductName Name of the back-office application. String O O
ProductVersion Version of the back-office application. String O O
New Auxiliary type ProductList
Product The list of occurrences of the VendorName, Product [0..3] O O

ProductName, and ProductVersion.
New Auxiliary type Digest
DigestRef Identification of a digest. DigestRef M M
DigestValue Value of a digest identified by DigestRef. DigestValue [0..1] O O
New Auxiliary type DigestList
Digest The list of occurrences of the Digest. Digest [1..8] O O
15 July 2011 475

Overview
This section provides a brief overview of the changes to the data elements in revision 2.0.3.

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
RecipientDN The DN which identifies the recipient for RecipientDN [1..1000] O O

the distribution of a message or file.
New Auxiliary type ThirdPartyList
ThirdPartyDN The DN which identifies the third party for ThirdPartyDN [1..30] O O
the copy of a message or file.
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.

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:
<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:SwInt="urn:swift:snl:ns.SwInt".
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
Revision The revision to a version of an XML String M(2) M

schema.
Absence of the Revision element indicates
that the document has revision 0 ("zero")
Header Contains all information relevant to the Header M M

processing of Alliance Access.
15 July 2011 477

Body Contains the message "text". Present in a Any M O

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).
(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.
( See "Message" Message M M

Message
|
HistoryReport See "HistoryReport" HistoryReport -- M

|
TransmissionReport See "TransmissionReport" TransmissionReport -- M

|

DeliveryNotification See "DeliveryNotification" DeliveryNotification -- M

|
DeliveryReport See "DeliveryReport" DeliveryReport -- M

|
MessageStatus See "MessageStatus" MessageStatus -- M

|
SessionStatus See "SessionStatus" SessionStatus -- M

)
D.5.2.3.2 Message
Message elements
SenderReference Reference provided by the application for String M M

reconciliation (see "Message Reconciliation
Scenario") of a DataPDU carrying a
message with the corresponding report
DataPDUs.
Length is 70 characters.
MessageIdentifier The identification of the message. String M M

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: String M M
• 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

Note This list is not exhaustive.

New values may be
introduced by new or
updated deployment
packages installed on
Alliance Access.
SubFormat The message sub-format. Enumeration(2) O M

• 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 M M

"AddressInfo").
Receiver The address of the message receiver (see AddressInfo M M

"AddressInfo").
InterfaceInfo General information managed by Alliance InterfaceInfo O O

Access (see "InterfaceInfo").
NetworkInfo Network-related information managed by NetworkInfo O/M(3) O

Alliance Access (see "NetworkInfo").
SecurityInfo Security-related information managed by SecurityInfo O O

Alliance Access (see "SecurityInfo").
SAAInfo Information about the Alliance Access SAAInfo O O

instance that processes the message.
FileLogicalName Logical name of the file (1 to 254 String O O

characters).
(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.
UserReference The Message User Reference. String O O

For FIN, this corresponds to the MUR (field
108 of block 3).
For SWIFTNet, this is the RequestRef (part
of the InterAct RequestHeader).
RoutingCode Information to influence routing in Alliance String O O

Access. The code entered here is visible


through the routing keyword 'Routing_code'
(see "RoutingInstruction").
ValidationLevel Requested message validation level. Enumeration O --

• None
• Minimum
Extract routing keywords from message
text
• Intermediate
MT messages: Minimum + syntax
validation
MX messages: same as Minimum
• Maximum
Same as Intermediate
Alliance Access configuration.
IsModificationAllowed If set to true, then the message can be Boolean O --

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.
Access configuration.
RoutingInstruction Specifies where the message has to be RoutingInstruction O --

created in Alliance Access (see
"RoutingInstruction").
Alliance Access message partner
configuration.
Currently not applicable to MQSA: if
present, it is ignored.
MessageCreator The Alliance Access component that Enumeration O O

• SWIFTNetInterface
• FINInterface
• Workstation
• Messenger
• Other
15 July 2011 481


Only present for Original or Copy
instances.
From: the value is ignored(1).
MessageContext The Alliance Access message instance Enumeration O M

type:
• Original
• Copy
• Report
From: the value is ignored(1).
MessageNature The message nature. Enumeration O M

• 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 ProductList O O

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.
Priority The Network priority. Enumeration O M

• Normal
• Urgent
• System (FIN only)

IsPossibleDuplicate From: the application indicates that the Boolean O M

message is a PDE (Possible Duplicate
Emission).


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 PDEPDM O O

(PDEs and PDMs). [1..N]
From: for Output messages only.
IsNotificationRequested Indicates whether a positive delivery Boolean O O

notification is requested.
Can also be used for Real-time FileAct.
Not present for Output messages.
Service The SWIFTNet service name. String O M

Mandatory for SWIFTNet.
For FIN, the value must be 'swift.fin' when
specified.
Network The network over which the message has Enumeration O M

been transmitted.
• Application
• SWIFTNet
• FIN
• Other
SessionNr The network session number. Integer O M

SeqNr The network sequence number. Integer O M

( SWIFTNet-specific network information SWIFTNetNetworkInfo O O

SWIFTNetNetworkInfo (see "SWIFTNetNetworkInfo").
|
FINNetworkInfo FIN-specific network information (see FINNetworkInfo O O

) "FINNetworkInfo").
D.5.2.3.2.2.1 SWIFTNetNetworkInfo
SWIFTNetNetworkInfo elements
RequestType Contains the Request Type of the String O O

message. If not present, then the request
type is assumed to be the same as the
message identifier.
15 July 2011 483

SWIFTRef The reference generated by the central String O O

SWIFT infrastructure.
Always present for Output messages,
Transmission Reports with delivery status
Acked, and Delivery Reports.
Format:
SWITCHid-YYYY-MM-
Where:



within a given second
• the timestamp is the time of generation

of the reference in UTC
SNLRef The reference generated by the emitting String O O

SWIFTNet Link.
Always present for Output messages,
Transmission Reports with delivery status
Acked, and Delivery Reports.
Format:
SNLid-YYYY-MM-
of "SWIFTRef".
Reference The reference generated by Alliance String O O

Access (for messages sent) or by the
correspondent application (for messages
received).
SNLEndPoint The SWIFTNet Link endpoint. String O O

SnFQueueName The store-and-forward queue name. String O O

Store-and-forward messages only.
SnFInputTime SWIFTNet storage location and time of a String O O

store-and-forward request (UTC).
Format:
nnnn:YYYY-MM-DDTHH:MM:SS


Where nnnn is the SWIFT internal storage
identifier.
SnFDeliveryTime The time (UTC) when the message was String O O

acknowledged by the receiver.
Format:
CreationTime The time (local system time in UTC) when String O O

the initial message request was created.
Format:
The CreationTime is only meaningful for an
output message.
ValidationDescriptor MVal processing result. Any O O

ResponseResponderDN The responder DN of the response. String -- O

ResponseSWIFTRef The response reference generated by the String -- O

central SWIFT infrastructure.
Format:
SWITCHid-YYYY-MM-DDTHH:
MM:SS.procid.digitsZ
Where:



within a given second
• the timestamp is the time of generation

of the reference in UTC
ResponseSNLRef The reference generated by the SWIFTNet String -- O

Link of the responding application.
Format:
SNLid-YYYY-MM-DDTHH:
MM:SS.procid.digitsZ
of "SWIFTRef".
ResponseReference The reference generated by the responding String -- O

application.
Format: see "SwiftReference" in
SWIFTNetNetworkInfo.
15 July 2011 485


IsPossibleDuplicateRespon Indicates whether the response is a Boolean -- O

se possible duplicate.
ResponseValidationDescri MVal processing result of the response. Any -- O

ptor Real-time messages only.
PayloadAttributes List of names and values associated to PayloadAttributeList - O

attributes of SWIFTNet message requests.
Example: the attribute "type" on the
SwInt:RequestPayload.
ResponsePayloadAttribute List of names and values associated with PayloadAttributeList - O

s attributes of SWIFTNet message
responses.
Example: the attribute "type" on the
SwInt:ResponsePayload.
IsCopyRequested True when the SWIFTNet copy feature is Boolean O O

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.
IsAuthNotificationRequeste Request a positive Authorisation Boolean O -

d Notification for Y-Copy service.
CopyInfo Provides copy-processing related Sw:Copy O O

information.
TransferRef The unique reference of the file transfer. String O O

StoredTransferRef The unique reference of the file transfer String - O

notification.
For Reception only on store and forward.
OrigSnFRef Present if a notification relates to a copy. String - O

For Reception only on store and forward.
TransferDescription Information about the file transfer (free String O O

text).
TransferInfo Structured data that the receiver can use String O O

for automatic processing of the file transfer.
FileDescription Information about the file (free text). String O O
FileInfo Structured data that the receiver can use String O O

for automatic processing of the file.
HeaderInfo Sw:HeaderInfo in end-to-end control data. XML O O

Sometimes this element is mandatory. See
"The HeaderInfo element" on page 487.
NotificationResponderDN Delivery Notification Receiver DN (for Real- String O O

time FileAct).


Not present for Output messages.
NotificationRequestType Delivery Notification Request Type (for String O O

Real-time FileAct).
FileStartTime The time when the file transfer was started. String O O
Format:
YYYYMMDDHHMMSS
FileEndTime The time when the file transfer ended. String O O

Format:
YYYYMMDDHHMMSS
OverdueWarningTime Time and date in UTC after which store String O O

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.
Format:
OverdueWarningDelay Number of minutes after which store and String O O

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.
RecipientList The list of recipients to which the message/ RecipientList O --

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.
ThirdPartyList The list of third party recipients to which the ThirdPartyList O O

message or file must be copied in case of
dynamic T- or Y-Copy.
IsRecipientListPublic This element, when absent or equal to Boolean O --

TRUE, indicates that the RecipientList is
public and has to be forwarded to all
Recipients.
DistributionInfo Distribution information provided to the Sw:DistributionInfo O O

recipient of a distributed message or file.
From: for output messages only.
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

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 Request General FileAct Header Solution-specific FileAct

Types Documentation Header requirements
swift.remit.fast All Standards MX - General

Information Guide(1) Workers' Remittances Standards
swift.remit.fast!p MX Message Implementation
Guidelines(1)
swift.remit.fast!x
(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
UserPriority FIN User Header field 113; Banking Priority String O O
CopyService Value-added service ID String O O
MessageSyntaxVersion The syntax version (for example, 0505). String O M

From: Output messages only.
IsRetrieved Indicates whether the message is a retrieved Boolean O O

message.
ReleaseInfo FIN User Header field 115: information from String O O

Central Institution to the receiver of payment
message.
ValidationIdentifier FIN User Header field 119: Validation Identifier String O O

Cannot be present if the MessageIdentifier
contains the optional Message User Group
(see "Message").
CorrespondentInputRefe The sender logical terminal, session, and String O O

rence sequence numbers used by the correspondent
to send the message.


CorrespondentInputTime Time and date the message was sent by the String O O
correspondent.
LocalOutputTime Time and date the message was received by String O O

this interface.
SystemOriginated SYS trailer String O O

DelayedMessage Delayed Message trailer String O O

FINUserHeader Full FIN user header (block 3 of FIN message) String O O
D.5.2.3.2.3 SecurityInfo
SecurityInfo elements
This structure contains all the security-related information managed by Alliance Access to
process messages.
IsSigningRequested Indicates whether signing of the message Boolean O --

is required upon emission:
• SWIFTNet: if specified, overrides the

Alliance Access emission profile
configuration.
• FIN: if specified, the value is ignored.
RMAResult The result of the Authorisation verification. Enumeration O O

• Success
• Bypassed
• NoRecord
• NotEnabled
• InvalidPeriod
• Unauthorised
Not present when message is not subject
to RMA authorisation.
( SWIFTNet-specific security information SWIFTNetSecurityInfo O O

SWIFTNetSecurityInfo (see "SWIFTNetSecurityInfo").
|
15 July 2011 489

FINSecurityInfo FIN-specific security information (see FINSecurityInfo O O

) "FINSecurityInfo").
D.5.2.3.2.3.1 SWIFTNetSecurityInfo
SWIFTNetSecurityInfo elements
IsNRRequested Indicates whether non-repudiation is Boolean O --

requested.
Access emission profile configuration.
SignerDN The Signer DN. String O O

NRType Non-repudiation processing information Enumeration O O

(Type).
• SvcOpt
• SvcMand
NRWarning Non-repudiation processing information String O O

(Warning).
SignatureResult The signature result. Enumeration O O

• Success
• Bypassed
• Failed
SignatureValue The signature value. Any O O

ResponseNRType Non-repudiation processing information Enumeration -- O

(Type) for the response.
• SvcOpt
• SvcMand
ResponseNRWarning Non-repudiation processing information for String -- O

the response (Warning).
ResponseSignatureResult The signature result for the response. Enumeration -- O


• Success
• Bypassed
• Failed
ResponseSignatureValue The signature value for the response. Any -- O

FileDigestAlgorithm Name of the file digest algorithm ("SHA-1"" String O O

or "SHA-256"). 1 to 20 characters.
FileDigestValue Value of the file digest. 1 to 50 characters. String O O
DigestList Allows to override the usual digest(s) used DigestList O O

for MX and File messages. Optional and
composed of up to 8 digests.
Composed of 2 elements:
• DigestRef (mandatory)
• DigestValue (optional).
ThirdPartySignerDn The Third Party Signer DN if the digest on String O O

Sw:ThirdPartyToSenderInfo is received in a
second signature.
D.5.2.3.2.3.2 FINSecurityInfo
FINSecurityInfo elements
ChecksumResult The result of the FIN checksum validation. Enumeration O O

• Success
• Failed
ChecksumValue The value of the FIN checksum. String O O

PACResult The result of the PAC verification. Enumeration O O

• Success
• SuccessFuture
• SuccessOld
• Bypassed
15 July 2011 491


• NoKey
• Failed
• InvalidDigest
• InvalidSignerDN
• InvalidCertPolicyID
PACValue PAC value: String O O
• 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. Enumeration O O

• Success
• SuccessFuture
• SuccessOld
• Bypassed
• NoKey
• Failed
• InvalidDigest
• InvalidSignerDN
• InvalidCertPolicyID
MACValue MAC value. String O O

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).
MACSignatureValue Signature of the MAC equivalent digest Any O O

(also includes the PAC1(1) equivalent digest
if required).

PAC2SignatureValue Signature of the PAC2(2)

equivalent digest. Any 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.
SenderReference SenderReference that the application has String -- M

provided when sending the corresponding
message.
OriginalInstanceAddressee The address of the receiver of the original AddressFullName -- M

ReportingApplication The Alliance Access component that Enumeration -- M

generated the report
• FINInterface
• TrafficReconciliation
• Other
SAAInfo Information about the Alliance Access SAAInfo - O

Interventions The list of interventions. HistoryIntervention -- M

[1..N]
IsRelatedInstanceOriginal Indicates whether this report is about an Boolean -- M

Original or a Copy instance:
• true: RelatedInstanceAddressee is not

present
15 July 2011 493


• false: RelatedInstanceAddressee is
possibly present
RelatedInstanceAddressee If this report concerns a Copy instance, AddressFullName -- O

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.
MessageCreator The Alliance Access component that Enumeration -- M

• FINInterface
• Workstation
• Messenger
• Other
IsMessageModified Indicates whether the message has been Boolean -- M

MessageFields The level of detail that Alliance Access Enumeration -- M

provides about the original Message (next
element), as defined in the Alliance Access
configuration.
• 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.


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 -- O

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.
SenderReference SenderReference that has been provided String -- M

by the application when sending the
corresponding message.
ReconciliationInfo Used by the application to reconcile a String -- O

Delivery Notification with the original
message through a Report (see "Message
Reconciliation Scenario").
• 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. Enumeration -- M

• NetworkAcked
15 July 2011 495


• 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.


• FINInterface
• Other
NetworkInfo Network-related information managed by NetworkInfo -- M


Interventions The list of interventions. Intervention -- M

[1..N]

Original or a Copy instance:

present
possibly present


"AddressFullName").
IsRelatedInstanceOriginal (previous
element) has a value of false.

• FINInterface
• Workstation
• Messenger
• Other

MessageFields See the definition of MessageFields in Enumeration -- M

"HistoryReport".

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.
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


See "Message Reconciliation Scenario" for
an explanation of the reconciliation
scenario.
ReceiverDeliveryStatus The Delivery Notification status. Enumeration -- M

• 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. String -- M

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 AddressInfo -- O

Notification (see "AddressInfo").
FIN only.
InterfaceInfo General information managed by Alliance InterfaceInfo -- O

Access (see "InterfaceInfo").
NetworkInfo Network-related information managed by NetworkInfo -- O

SecurityInfo Security-related information managed by SecurityInfo -- O

Alliance Access (see "SecurityInfo").
FIN only.


(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.
SenderReference SenderReference that the application has String -- M

provided when sending the corresponding
message.
ReceiverDeliveryStatus The Delivery Notification status. String -- M

• RcvDelivered
• RcvAborted
• RcvDelayedNak
• RcvFCPReleased
• RcvOverdue
See "DeliveryNotification".


• FINInterface
• Other
NetworkInfo Network-related information managed by NetworkInfo -- M


Interventions The list of interventions. Intervention -- M

[1..N]

Original or a Copy instance
15 July 2011 499



present
possibly present

"AddressFullName").
IsRelatedInstanceOriginal has a value of
false.

• FINInterface
• Workstation
• Messenger
• Other

MessageFields See the definition of MessageFields in Enumeration -- M

"HistoryReport".

D.5.2.3.7 MessageStatus
MessageStatus elements
SenderReference Sender reference that had been provided String -- O

by the application when sending the
corresponding Message.
SeqNr The sequence number of the concerned Integer -- O

DataPDU in the file.
IsSuccess Indicates the result of the processing of the Boolean -- M

DataPDU by Alliance Access:
• true if the DataPDU was processed

successfully by Alliance Access


• false if an error occurred during the
processing of the DataPDU.
ErrorCode Code identifying the error. String -- O

Only present if the element IsSuccess has
value false.
ErrorText Text associated with the error code. String -- O

value false.

D.5.2.3.8 SessionStatus
SessionStatus elements
MessagePartner The name of the message partner. String M M
CreationTime Date and Time the SessionStatus String M M

DataPDU was generated.
Format: 'YYYYMMDDHHMMSS'
SessionNr The session number. Integer M M
InputFile The name of the input file. String -- O
IsSuccess Indicates the result of the processing by Boolean M M

Alliance Access:
• 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. String O O

a value of false.
ErrorText Text associated with the error code. String O O

a value of false.
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


Access and message from the message
partner to Alliance Access.
Only present for SOAP adapters.
Accepted Depends of the SessionDirection setting: Integer O O
• 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: Integer O O
• 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.
a value of "true".
AcceptedFromMessagePar The number of messages accepted by Integer O O

tner Alliance Access.
a value of true and for the SOAP
connection method.
RejectedFromMessagePart The number of messages rejected by Integer O O

ner Alliance Access.
connection method.
AcceptedToMessagePartn The number of messages sent by Alliance Integer O O

er Access and accepted by the message
partner.
connection method.
RejectedToMessagePartne The number of messages sent by Alliance Integer O O

r Access and rejected by the message
partner.
connection method.

D.5.2.3.9 Auxiliary Types
D.5.2.3.9.1 AddressInfo
AddressInfo elements
( Sender: The first 9 characters identify the String M M

BIC12 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.
Nickname The correspondent nickname. String M --

| Only for a Receiver address.
FIN only.
Currently not applicable to MQSA.
DN The DN identifying the sender or receiver String M M

) 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
• 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 Detailed address information (see AddressFullName O O

"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.
15 July 2011 503

D.5.2.3.9.2 AddressFullName
AddressFullName elements
X1 The correspondent X1 part: the Institution String M M

BIC11.
X2 The correspondent X2 part: Department or String O O

Application name.
Present if correspondent is of type
Department or Application or Individual.
X3 The correspondent X3 part: if the String O O

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.
X4 The correspondent X4 part: the firstname. String O O

Present if the correspondent is of type
Individual.
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
D.5.2.3.9.3 RoutingInstruction
RoutingInstruction elements
RoutingFunction The routing function to be performed on the Enumeration M --

message.
• 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 The target routing point. String O --

Present if the element RoutingFunction has
value "DisposeToRoutingPoint".

RoutingStep The requested message disposition state. Enumeration O --

The corresponding routing point name is
listed between parentheses.
• 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
( FIN only: the PDE value. String O M

PDE
|
PDM FIN: the PDM value. String O M

) SWIFTNet: the store and forward PDM
history.
D.5.2.3.9.5 Intervention
Intervention elements
This type is only used in the elements of type TransmissionReport and DeliveryReport.
IntvCategory Intervention category. Enumeration -- M

present if TransmissionReport
• DeliveryReport
present if DeliveryReport
• TransmissionResponse
only present in TransmissionReport or
HistoryReport for MX Input messages.
CreationTime The intervention creation date and time. String -- M

Format: "YYYYMMDDHHMMSS".
15 July 2011 505

OperatorOrigin The name of the operator that triggered the 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.
IntvCategory Intervention category. Enumeration -- M

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. String -- M

Format: "YYYYMMDDHHMMSS"'.
OperatorOrigin The name of the operator that triggered the String -- M

Text The intervention text. String -- M

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:
InstanceName The instance name of the Alliance String O M

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.
UserName The OS user that runs the Alliance String O M

Access server.
Unit The Alliance Access Unit to which the String O M

message belongs.
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
PseudoAckNack Alliance Access-generated Pseudo SWIFT String -- M

Acknowledgement.
SwGbl:Status Optional SWIFTNet report status. SwGbl:Status -- O
15 July 2011 507

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:
Code Text Description
T02 Value of the first occurrence of Transmission error

<SwGbl.Details><SwGbl:Code> When the value of the element
if present <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 In the context of FileAct, the file sent is
correspondent 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 In the context of FileAct, the file transfer
(remote abort) or File aborted by has been aborted either remotely by the
<user> (local abort) correspondent during reception, or locally
by the user sending the file.
T03 Value of the first occurrence of All other cases.

<SwGbl.Details><SwGbl:Code>
LEN - In the context of FIN, the total FIN

message length exceeds 10k.

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
SwGbl:StatusAttributes Report status of top-level processing of SwGbl:StatusAttributes -- M

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).
SwGbl:StatusAttributes
SwGbl:Severity Possible values: String -- M
• Fatal
• Transient
• Logic
• Success
• Warning
SwGbl:Code Status code. The list of error codes is String -- M

available in SWIFTNet Link Error Codes
(part of the SWIFTNet Link documentation
set).
SwGbl:Parameter Content depends on the error. Any [0..N] -- O
SwGbl:Text Textual description. No processing, except String -- O

display/print for information, must be
performed on this element.
15 July 2011 509

SwGbl:Details Lower level detailed report. SwGbl:Details [0..N] -- O
SwGbl:Details
SwGbl:Code Status code. String -- M
SwGbl:Text Textual description. String -- O
Sw:SnFPDMHistory
Sw:SnFPDMHistory In case of previous delivery attempts, gives Sw:SnFDeliveryHistory -- M

the delivery attempt history.
Sw:SnFDeliveryHistory
Sw:SnFDeliveryInfo Message delivery information. Sw:SnFDeliveryInfo -- O

In case of disaster take-over (SWIFT side), [0..N]
all messages present in the queue at the
moment of the disaster are flagged for
possible duplicate delivery, but without
delivery information.
Sw:SnFDeliveryInfo
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 String -- O

the message was delivered.
Format:
<queue>:(d|p):<6 digit session
number>
SwInt:SNLId SNL ID of the physical SWIFTNet Link String -- O

where message was delivered.
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>

<SwGbl:Code>See Error Guide</SwGbl:Code>
<SwGbl:Text>One liner error description</SwGbl:Text>
<SwGbl:Action>Retry Message</SwGbl:Action>
</SwGbl:Status>
</Sw:RetryReason>
</Sw:SnFDeliveryInfo>
</Sw:SnFPDMHistory>
Sw:NotifSnFRequestHandle
Sw:SnFRef Store-and-forward message reference of String -- M

the notification.
Contains the SwiftRef of the original
message (see
Sw:SnFRefType Type of message for which this notification String -- M

is provided.
Possible value:
• InterAct
Sw:AcceptStatus Type of store-and-forward notification. String -- M

Possible values:
• Accepted
message accepted by the receiver
• Rejected
message rejected by the receiver
• Failed
SWIFT failed to deliver the message
Sw:AckSwiftTime The SWIFT acceptance time of the request String -- M

("Accepted", "Rejected") or generation time
of the delivery notification request ("Failed")
in UTC.
Format: YYYY-MM-DDTHH:MM:SSZ
Sw:AckDescription Provides information about the String -- O

acknowledgement.
Free text.
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

Sw:AckInfo Provides information about the String -- O

acknowledgement.
Structured data that the client can analyse.
the Sw:AckInfo contains the following:
SwRejectCode=<reject code>
Where reject code is:

SwGbl.MessageExpired
SwGbl.MaxRetryExceeded
SwInt:ValidationDescriptor
SwInt:ValResult Indicates the result of validation. String -- M

Possible values:
• Success
• Warning
• Fatal (not currently used)
SwInt:ValStatus This contains the details of error(s) found. SwGbl:Status -- O

More than one SwGbl:StatusAttributes can
be present.
Present if SwInt:ValResult is Warning.
Example:
<SwInt:ValStatus>
<SwGbl:Code></SwGbl:Code>
<SwGbl:Text></SwGbl:Text>
</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
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.

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

Message Sent by an Application to Alliance Access

The following shows an example of Message DataPDU sent by an application to Alliance
Access:
<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:
<Saa:DataPDU xmlns:Saa="urn:swift:saa:xsd:saa.2.0"
<Saa:Header>
<Saa:MessageStatus>
<Saa:SenderReference>REF10610311637</Saa:SenderReference>
<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.

The important information in this DataPDU is identified in bold:

<Saa:Header>
<Saa:ReconciliationInfo>061102SAARBEBBAXXX0023000049
</Saa:ReconciliationInfo>
<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:FINNetworkInfo>
<Saa:MessageSyntaxVersion>0605</Saa:MessageSyntaxVersion>
</Saa:FINNetworkInfo>
</Saa:NetworkInfo>
<Saa:Interventions>
<Saa:Intervention>
<Saa:Contents>{1:F21SAARBEBBAXXX0023000049}{4:{177:0611020938}{451:0}
{108:REF10610311637}}</Saa:Contents>
</Saa:Intervention>
<Saa:IsRelatedInstanceOriginal>true</Saa:IsRelatedInstanceOriginal>
<Saa:MessageCreator>ApplicationInterface</Saa:MessageCreator>
<Saa:IsMessageModified>false</Saa:IsMessageModified>
<Saa:MessageFields>HeaderAndBody</Saa:MessageFields>
<Saa:Message>
<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:FullName>
</Saa:Sender>
<Saa:Receiver>
<Saa:BIC12>SAARBEBBXXXX</Saa:BIC12>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:InterfaceInfo>
<Saa:UserReference>REF10610311637</Saa:UserReference>
<Saa:MessageContext>Report</Saa:MessageContext>
<Saa:MessageNature>Financial</Saa:MessageNature>
</Saa:InterfaceInfo>
<Saa:NetworkInfo>
<Saa:IsNotificationRequested>true
15 July 2011 515

</Saa:IsNotificationRequested>
</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: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

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:
<Saa:Header>
<Saa:DeliveryNotification>
<Saa:ReconciliationInfo>061102SAARBEBBAXXX0023000049
<Saa:ReceiverDeliveryStatus>RcvDelivered
</Saa:ReceiverDeliveryStatus>
<Saa:Receiver>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:InterfaceInfo>
<Saa:MessageCreator>FINInterface</Saa:MessageCreator>
<Saa:MessageContext>Original</Saa:MessageContext>
<Saa:MessageNature>Network</Saa:MessageNature>
<Saa:NetworkInfo>
<Saa:Priority>System</Saa:Priority>
<Saa:IsPossibleDuplicate>false</Saa:IsPossibleDuplicate>
<Saa:CorrespondentInputReference>061102DYLQXXXXHXXX0000413146
</Saa:CorrespondentInputReference>
<Saa:CorrespondentInputTime>20061102083900
</Saa:CorrespondentInputTime>
<Saa:LocalOutputTime>20061102093900</Saa:LocalOutputTime>
<Saa:SystemOriginated>{SYS:}</Saa:SystemOriginated>
</Saa:NetworkInfo>
<Saa:SecurityInfo>
<Saa:ChecksumValue>8BB8247F0C2E</Saa:ChecksumValue>
</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

reconciled with the TransmissionReport DataPDU and the Message DataPDU through the
SenderReference element. The important information in this DataPDU is identified in bold:
<Saa:Header>
<Saa:ReportingApplication>TrafficReconciliation
</Saa:ReportingApplication>
<Saa:NetworkInfo>
<Saa:IsNotificationRequested>true</Saa:IsNotificationRequested>
</Saa:NetworkInfo>
<Saa:Interventions>
<Saa:Intervention>
<Saa:Contents>{175:0938}{106:061102SAARBEBBAXXX0023000049}
{108:REF10610311637}{175:0938}{107:061102SAARBEBBAXXX0023000298}
</Saa:Contents>
</Saa:Intervention>
<Saa:MessageFields>NoOriginal</Saa:MessageFields>
</Saa:Header>
</Saa:DataPDU>
D.5.2.5.1.2 Reception Flow DataPDUs
Message Sent by Alliance Access to the Application

Access upon reception of a message from the network:
<Saa:Header>
<Saa:Message>
<Saa:SenderReference>OSAARBEBBXXX199TRN MSG1000
<Saa:SubFormat>Output</Saa:SubFormat>
<Saa:Sender>

<Saa:FullName>
</Saa:FullName>
</Saa:Sender>
<Saa:Receiver>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:InterfaceInfo>
<Saa:MessageCreator>FINInterface</Saa:MessageCreator>
<Saa:NetworkInfo>
<Saa:DuplicateHistory>
<Saa:PDE>{PDE:}</Saa:PDE>
</Saa:DuplicateHistory>
<Saa:CorrespondentInputReference>061102SAARBEBBAXXX0023000049
</Saa:CorrespondentInputReference>
<Saa:CorrespondentInputTime>20061102093800
</Saa:CorrespondentInputTime>
<Saa:LocalOutputTime>20061102093800</Saa:LocalOutputTime>
</Saa:NetworkInfo>
<Saa:SecurityInfo>
<Saa:RMAResult>Success</Saa:RMAResult>
<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:KeyInfo>
<SwSec:SignDN>cn=rma1,o=saarbebb,o=swift
</SwSec:SignDN>
</SwSec:KeyInfo>
<SwSec:Manifest>
15 July 2011 519

<Sw:Reference>
<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: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

Access:
<Header>
<Message>
<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>
</InterfaceInfo>
<NetworkInfo>
<Service>swift.eni</Service>
</NetworkInfo>
<SecurityInfo>
<SWIFTNetSecurityInfo />
</SecurityInfo>
</Message>
</Header>
<Body>

<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:
<Saa:Header>
<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:
<Saa:Header>
<Saa:ReconciliationInfo>SWITCH21-2006-11-02T08:41:47.11481.1454972Z
<Saa:X1>SAAABEBBXXX</Saa:X1>
<Saa:ReportingApplication>SWIFTNetInterface
</Saa:ReportingApplication>
<Saa:NetworkInfo>
<Saa:Service>swift.eni</Saa:Service>
<Saa:Network>SWIFTNet</Saa:Network>
15 July 2011 521

<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:SWIFTNetNetworkInfo>
</Saa:NetworkInfo>
<Saa:Interventions>
<Saa:Intervention>
<Saa:Contents>
<AckNack>
<PseudoAckNack>{1:F21SAAABEBBAXXX000008000000001}{4:{177:0611020935}
{451:0}{311:ACK}{108:REF10610311505}}</PseudoAckNack>
</AckNack>
</Saa:Contents>
</Saa:Intervention>
<Saa:MessageFields>NoOriginal</Saa:MessageFields>
</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:
<Saa:Header>
<Saa:DeliveryNotification>
<Saa:ReconciliationInfo>SWITCH21-2006-11-02T08:41:47.11481.1454972Z
<Saa:MessageIdentifier>Delivery Notification</Saa:MessageIdentifier>
<Saa:InterfaceInfo>
<Saa:MessageCreator>SWIFTNetInterface</Saa:MessageCreator>
<Saa:MessageNature>Network</Saa:MessageNature>
<Saa:NetworkInfo>
</Saa:NetworkInfo>
</Saa:DeliveryNotification>
</Saa:Header>

<Saa:Body>
</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:
<Saa:Header>
<Saa:Message>
<Saa:SenderReference>OSAAABEBBXXX029REF10610311505
<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:FullName>
</Saa:Sender>
<Saa:Receiver>
<Saa:DN>o=saaabebb,o=swift</Saa:DN>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:InterfaceInfo>
<Saa:MessageCreator>SWIFTNetInterface</Saa:MessageCreator>
<Saa:NetworkInfo>
<Saa:Service>swift.eni</Saa:Service>
<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>
<SwInt:ValStatus>
15 July 2011 523

<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>
</SwInt:ValStatus>
</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>
hYWFiZWJiLG89c3dpZnQNCk9yaWctU046IDExNDc4MjUyNjcNCk1JQy1JbmZvOiBTSEExLCBSU0EsD
QogV1Bwb1QyU1R0OFYydzZ3NnhaV3d2c2R5bk9jTUpaQUtodHJpZklMNDNlNS9rdThmSHc4bWppUlp
seFNBYnRkUA0KIEl6Z2JrcDdKTDZ3WDI5WmVjWHVpTFpzZWJzbVFQRjBBR3RBU1hsaXZNK3NPK29BV
EV0emRnMi9naE8rR1c0NDkNCiBONk1IYmU3RDlRN3dDa2FOQnRCTS9ucTJOVkhvM050dXY5dFBOcWN
Iamg0b2NtamtlV0g2TjZWVzRkUWU4SW1aDQogVFZxRnhpME9ZTkRtcmQ1aW1INUQzUXkzdldIYVo4K
zFDbHltMFNkckViS2YxWUcvOXA1Z05YaXBMN1MxcWxPbg0KIG0vMjBUSkdTd2hKSVdaajY4aW9GcjN
5WHBhZDRTWUpGSjVseEhFRFBUL1hRVjNkbFNYazl3eHNoRTVVYWd0aDcNCiBrME5EdmNzRER1RlYvM
jZZcmY3d3NnPT0NCg==</SwSec:CipherKey>
<SwSec:MemberRef>RequestDescriptor.SwiftRequestRef
</SwSec:MemberRef>
<SwSec:SignDN>cn=rma2,o=saaabebb,o=swift</SwSec:SignDN>
</Saa:SignatureValue>
</Saa:SWIFTNetSecurityInfo>
</Saa:SecurityInfo>
</Saa:Message>
</Saa:Header>
<Saa:Body>
<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>

</Saa:DataPDU>
D.5.2.5.3 SessionStatus DataPDU Sent by Alliance Access to the Application
Case of a successful session

xmlns:SwInt="urn:swift:snl:ns.SwInt"
xmlns:SwSec="urn:swift:snl:ns.SwSec">
<Saa:Header>
<Saa:SessionStatus>
<Saa:MessagePartner>CVEFileInput</Saa:MessagePartner>
<Saa:InputFile>D:\Batch\Input\success.mx</Saa:InputFile>
<Saa:Accepted>10</Saa:Accepted>
<Saa:Rejected>0</Saa:Rejected>
</Saa:SessionStatus>
</Saa:Header>
</Saa:DataPDU>
Case of an aborted session

xmlns:SwInt="urn:swift:snl:ns.SwInt"
xmlns:SwSec="urn:swift:snl:ns.SwSec">
<Saa:Header>
<Saa:SessionStatus>
<Saa:MessagePartner>CVEForcedInput</Saa:MessagePartner>
<Saa:InputFile>D:\Batch\Input\formatconflict.rje</Saa:InputFile>
<Saa:IsSuccess>false</Saa:IsSuccess>
<Saa:ErrorCode>EFILEINVFORMAT</Saa:ErrorCode>
<Saa:ErrorText>
DataPDU format does not match value configured in SAA
</Saa:ErrorText>
</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

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.

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
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
15 July 2011 527

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 Version 2 Mapping
DataPDU SenderReference {PDUType}.SenderReference
Message Message
Report {PDUType}
LogicalReply MessageStatus
Report Addressee {PDUType}.OriginalInstanceAddressee
OrigMessageFields {PDUType}.MessageFields
See note 1.
OrigMessage {PDUType}.Message
ReportLPI {PDUType}
TransmissionReport TransmissionReport
DeliveryReport DeliveryReport

Message 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
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.
MessageSRI UserReference Message.InterfaceInfo.UserReference
UserPDE Message.NetworkInfo.IsPossibleDuplicate
MessageTPI 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.
15 July 2011 529

MessageLPI 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
ReportLPI 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
DeliveryReport 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

TransmissionReport 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
Intervention IntvCategory Intervention.InterventionCategory
CreationTime Intervention.CreationTime
ApplicationOrigin Redundant information, also present in Text. Not

present in Version 2.
OperatorOrigin Intervention.OperatorOrigin
Text Intervention.Contents
SWIFTNetSecurityAttribute 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
15 July 2011 531

SWIFTNetRequestAttribute 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.
MessageOrigin 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.
TargetApplication TargetApplicationRule RoutingInstruction.RoutingFunction

See note 5.
TargetRoutingPoint RoutingInstruction.RoutingPoint

LogicalReply SenderReference MessageStatus.SenderReference
SuccessIndication MessageStatus.IsSuccess
ErrorText MessageStatus.ErrorText
Address Nickname AddressInfo.Nickname
FullName AddressInfo.AddressFullName
In Version 2, when using FullName, you must also
specify either the BIC12, the DN, or the Nickname.
AddressFullName X1 AddressFullName.X1
X2 AddressFullName.X2
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:
ApplicationNetwork Application
SwiftNetNetwork SWIFTNet
OtherNetwork Other
3. The enumerated type 'DispositionState' has been renamed to 'RoutingStep' with the
following mapping:
Verify Verify
15 July 2011 533

Authorise Authorise
Modify Modify
Ready ReadyToSend
4. The enumerated type 'CBTApplication' has been renamed to 'MessageCreator' with the
following mapping:
ApplicationInterface ApplicationInterface
SwiftnetInterface SWIFTNetInterface
MessageEntry Workstation
MessengerAdapter Messenger
Other Other
5. The enumerated type 'TargetApplicationRule' has been renamed to 'RoutingFunction' with

the following mapping:
InternalRouting Route
CBTApplication DisposeToRoutingStep
RoutingPoint DisposeToRoutingPoint
D.6 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

(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 Description Type From To To

(Resp
)
UUMID The UUMID of the message. String (45 bytes) padded O O O

Present if the option Transfer with spaces
UUMID is selected in the
message partner profile.
Message The business data that is being MQMTMessage M M O

exchanged between
applications.
This can contain the one of the
types of information, as
outlined in "MQMTMessage"
on page 536.
OriginalMessage A FIN message, with an FIN message -- O --

optional block 4. (1)
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 The error code that applies if The field contains the offset -- -- O
ode the requested level of in block 4 that caused the
message validation has failed.
error, as follows:
Present if: {REP:{ERR:
(<error_information>)}
• an error is reported during }
message processing
<error information> is a
(Feedback element in the
string, such that:
MQ Message Descriptor
does not contain MQFB_PAN), <error_code> - <error
explanation> at
and offset <offset>
• Transfer Validation Code

is selected in the message
partner profile.
15 July 2011 535

Element Description Type From To To

(Resp
)
S-Block Present if: S-Block O O --

See "Codes in the Trailer
• Transfer SAA Information (Block S)" on page 538
is selected and Use MQ and "Routing Code Trailer"
Descriptor is not selected on page 541.
• 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.

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
05- a network-formatted transmitted intervention
NetworkFormattedTransmitted
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

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 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.
D.7 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

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 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).
D.7.2 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

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:
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
D.7.5 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.

Example
{TRN:<trn-value>}
Note The generation of a {TRN:<trn-value>} trailer always implies the presence of a

{CON:} trailer.
D.7.7 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:
Tag Meaning
COP:P Message is a primary copy
COP:S Message is a secondary copy
D.7.9 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

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.

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 Disposition option in the Reception tab.
Note 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

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

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.
Note The generic check does not validate the contents or structure of the text block.
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 This level is provided to allow for a possible future level of message
validation. Today this level performs the same checks as Medium
validation.
Important 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

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.

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
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
E.4 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.

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

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. 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.
3. 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.

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

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 Receiving logical -

terminal 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 Alliance Access does not changed whether the message partner has the
permission to bypass verification and authorisation.
2. 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

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

• networkApplicationName
dispositionState targetApplicationRule networkApplicationName Permissions or Action

message partner
profile settings
omitted or any valid omitted omitted or not applicable according to

value applicationInterface or default
swiftInterface disposition set in
message partner
profile or Run
Session or Start
Session window
cancel cBTApplication omitted or not applicable complete the

applicationInterface or message
swiftInterface
fix cBTApplication omitted or not applicable send to

applicationInterface or _MP_mod_text
swiftInterface queue
verify cBTApplication omitted or not applicable send to

applicationInterface or _MP_verificatio
swiftInterface n queue
authorise cBTApplication omitted or No permission to send to

applicationInterface or bypass Verification _MP_verificatio
swiftInterface on Msg Type or n queue
Currency code
given
authorise cBTApplication omitted or Permission to send to

applicationInterface or bypass Verification _MP_authorisat
swiftInterface on Msg Type and ion queue
Currency code is
given
ready cBTApplication omitted or No permission to send to

applicationInterface or bypass Verification _MP_verificatio
swiftInterface on Msg Type or n queue
Currency code is send to
given; _MP_authorisat
and ion queue
No permission to
bypass
authorisation on
Msg Type or
Currency code
given.
applicationInterface Permission to send to first exit

bypass Verification point assigned in
on Msg Type and the MP profile
Currency code is
given.
and
Permission to
bypass
Authorisation of
Msg Type and
Currency code is
given.
swiftInterface Permission to send to

bypass Verification _SI_to_SWIFT
on Msg Type and queue
15 July 2011 551

dispositionState targetApplicationRule networkApplicationName Permissions or Action

message partner
profile settings
Currency code is
given.
and
Permission to
bypass
Authorisation of
Msg Type and
Currency code is
given.
omitted or any valid internalRouting omitted or route according

value ignored applicationInterface or to defined
swiftInterface routing
omitted or any valid cIFPreferred omitted or route according

value ignored applicationInterface or to settings made
swiftInterface in the
Correspondent
Information File
omitted or any valid routingPoint omitted or Permission to move to the

value ignored applicationInterface or move messages is routing point
swiftInterface given specified in
targetRoutingPoi
nt

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 For Alliance Workstation, all Interactive sessions are run on the server machine.
F.1 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

Direct FileAct connection method
Access
MP 1 - Responder DN A
- Service
- ...
Payload Directory ... Correspondent

File SWIFTNet A
- Responder DN B Interface
MP 2
- Service
- ...
Directory ... Correspondent

Back Office B
MP 3 - Responder DN C
- Service
- ...

C
Direct FileAct
Message
D0540185
Partners
Configuration of Direct FileAct

A message partner profile with the Direct FileAct connection method must exist for each back-
office 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.

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 T-
Copy or Y-Copy mode.
15 July 2011 555

Direct FileAct versus File Transfer

The following table gives a summary the difference between Direct FileAct and File Transfer
connection methods:
Feature Direct File Transfer

FileAct
Configuration of bi-directional exchange: Allowed direction parameter No Yes

set to To & From Message Partner
Manual and automatic start of transfer sessions Yes Yes
One directory per correspondent on Alliance Access to hold payload Yes Yes
files that the back-office application sends and receives
Limited number of correspondents Yes No
FileAct transmission settings provided through:
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
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 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.
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 - 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
Payload Access
File Direct FileAct
Adapter (From) FileActMessage
2 3 4
Filename.ext
1 SWIFTNet
Response
Interface
File
Transmission Notification
Instance
6 5
Back Office Filename.ext
<Ref> OK 7
8 TR_REC
Response Delivery
File Direct FileAct Delivery Notification
9
Adapter (To) Notification (Optional)
Instance
Filename.ext
D0540188
<Ref> DL OK
Emission of a file to SWIFTNet

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.
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

• 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 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.
4. 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)

Tip 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.
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.
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
Payload
File Direct FileAct SWIFTNet
Adapter (To) Interface
4 3 2 1
FileActMessage
Filename*.SnRef
Back Office
D0540190
15 July 2011 559

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 back-
office 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.

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

Enhanced transmission status for Direct FileAct
Access
SWIFTNet
Transmission Notification Interface
Response
File Direct FileAct Instance
Adapter (To)
Filename.ext.err
Back Office
Transmission
Notification Notification
File Output Instance
Report Adapter (To) (Copy)
XMLv2
D0540189
F.1.6 Prepare to Use Direct FileAct
Purpose
Use the instructions in this section to prepare Alliance Access to communicate with a back-
office application using Direct FileAct.
Directories for Direct FileAct

The Direct FileAct adapter establishes an association between a set of directories and a FileAct
correspondent.

Access
MP 1 - Responder DN A
- Service
- ...
Payload Directory ... Correspondent

File SWIFTNet A
- Responder DN B Interface
MP 2
- Service
- ...

Back Office B
MP 3 - Responder DN C
- Service
- ...

C
Direct FileAct
Message
D0540185
Partners
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 back-
office 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

2. Configure a message partner profile for each service and for each correspondent that the
back-office application will communicate with.
Note that:

For From Message Partners, the directory is specified in Direct FileAct Input
Directory

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. Ensure that payload files do not exceed 250 MB.
F.2 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.

Payload FileAct
File Settings
+ File Transfer
Adapter
Any Data XMLv2
Back Office Notification

Report(s)
Alliance Access
D0540184
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.
User
Alliance Local Transfer FTP FTP
Application
Agent
D0540060
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

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 Directory Batch

(ST200 PCC)
RJE Directory Batch

(ST200 RJE)
CAS 1/2 Directory CAS Batch

(NDF/NIF)
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.
Tip The Direct FileAct connection method allows you to select a payload file directly, to
send to a counterparty.
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 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.
2. 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

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

What Happens During a Batch Output?
Application Interface
Message Partner
Application Message
Interface Processing
D0540062
outbound Function
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.

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

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
Session Parameter File Format Input Path Name Input File Formats
Initiation Recognition Recognized
Manual Not required Forced Specifies a pathname to DOS, RJE, MERVA/

an input message file 2, CAS1, CAS2
(ASN1, Text), XML
Manual Required Forced Specifies a pathname to DOS, RJE, MERVA/

an input parameter file 2, CAS1, CAS2
(ASN1), Text, XML

Session Parameter File Format Input Path Name Input File Formats
Initiation Recognition Recognized
Manual Not required Auto-recognition Specifies a pathname to DOS, RJE, MERVA/

an input message file 2, CAS2* (ASN.1),
XML
Manual Required Auto-recognition Specifies a pathname to DOS, RJE, MERVA/

an input parameter file 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 DOS, RJE, MERVA/

where input parameter 2, CAS1, CAS2
files may be found (ASN.1, Text), XML
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 DOS, RJE, MERVA/

where input parameter 2, CAS2* (ASN.1),
files may be found XML
Symbol Explanation
* CAS1 protocol versions are only recognised when the Format Recognition is
set to Forced
F.2.4.2 To Message Partner
Profile settings
Session Parameter Output Pathname Data Formats Output File Extension

Initiation File Available
Manual Not required Specifies a pathname DOS, RJE, Not required. File pattern in
where the output MERVA/2, the Output path name is
message file is placed CAS1, CAS2 used.
(ASN1, Text),
XML
Manual Required Specifies a pathname to DOS, RJE, Not required. The message
where the message file MERVA/2, file takes the file
and parameter file is CAS1, CAS2 extension, .out,
placed. If the parameter (ASN1, Text), automatically
file is not named XML
explicitly, then it is
automatically generated
with a proprietary format.
Automatic Required Specifies the directory DOS, RJE, Specify the extension of the
where the automatically MERVA/2, message file. If not
generated parameter and CAS1, CAS2 specified, then the default
message files are placed (ASN1, Text), extension .out is taken.
XML Any pattern specified in the
Output path name is
ignored.
15 July 2011 571

Session Parameter Output Pathname Data Formats Output File Extension

Initiation File Available
Automatic Not required Specifies a directory DOS, RJE, Specify the extension of the
where the generated MERVA/2, message file. If not
message file is placed CAS1, CAS2 specified, then the default
(ASN1, Text), extension .out is taken.
XML Any pattern specified in the
Output path name is
ignored.
F.2.5 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.

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

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 Application
Server communications
Common Communication Interface stack
TCP/IP TCP/IP
Access
Message Partner &

D0540066
User Application
A relevant message partner profile defines which protocol is used for a communication session
using CAS.

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: - UFS (User Format Services)

Sic
UNIX only: - UFS

Other networks
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

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'
User Interface Message Exchange

Services
Control
Send Receive
Common Application Server

Communications Stack
D0540067
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.

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
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:

The session is terminated using the Stop Session command.
Note During an interactive session, flow in either direction may be handled.
F.3.3 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

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
TermConfirm
D0540068
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.

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:
Reason :
Unable to find service name MPconn...
problem in hosts file :
15 July 2011 579


Reason : Unable to get host information for host name <host name>
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.

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

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/ Message is an output message, the message authentication

or authorisation and/or authorisation verification failed.
incorrect.
SAB Authentication and/ Message is an output message, the authentication and/or

or authorisation authorisation were bypassed.
bypassed.
FAI FINCopy Message is a FINCopy output message, the FINCopy

Authentication authentication verification failed.
incorrect.
FAB FINCopy Message is a FINCopy output message, the FINCopy

Authentication authentication code verification was bypassed.
bypassed.
FAN FINCopy Message is a FINCopy output message, the FINCopy

Authentication authentication is not present.
missing.
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 transmission-
related details for the network, session holder, session number, sequence number, and delivery
status.

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

Text Description
• Correct with old key
• Correct with future key
• Authentication bypassed
• Proprietary Authentication Code

trailer missing
*** FIN-Copy Authentication/Authorisation Prints only for an output MT message that

Result: <value> *** 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.

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 (Non-
Deliv 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

• 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 The end-of-message identifier is not printed when using the option for printing to a
file on Alliance Workstation.

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 back-
office application, and optionally, acknowledge a message received from Alliance Access
• Ack: acknowledge a message received from Alliance Access
15 July 2011 587

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.

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
Back
Application
Office
Server
Open
SOAP
OpenResponse
SOAP
Session Token
Put
SOAP
XMLv2 Message
Several
Put
PutResponse
requests
SOAP
XMLv2 MessageStatus
Close
SOAP
CloseResponse
SOAP
XMLv2 SessionStatus
D0540141
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 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.
15 July 2011 589

Emission of a file to SWIFTNet

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 Actions
Full 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.

FileAct mode Actions
Mixed 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.
5. For FileAct messages, Alliance Access automatically calculates the digest value of the
payload file, and stores the file in the database.
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
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

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
Back Alliance Access

Office Application
Server
Open
SOAP
OpenResponse
SOAP
Session Token
GetAck
SOAP
Several
GetAck
requests GetAckResponse
SOAP
XMLv2 Message
Close
SOAP
CloseResponse
SOAP
XMLv2 SessionStatus
D0540142

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 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.
4. 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
15 July 2011 593

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 back-
office 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:

It must be possible to open the Input Attachment Directory.

It must be possible to write to the Output Attachment Directory.

3. Configure a message partner profile for each back-office application that will use SOAP to
communicate with Alliance Access.
Note that:

From Message Partners: the directory is specified in Input Attachment Directory

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. Ensure that payload files do not exceed 250 MB.
F.5.5 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

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:
10 11 12 13 14 15 16 17 18 19 20 21
C C C W W W W W N N N N
D0540143
Window = 5

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:
10 11 12 13 14 15 16 17 18 19 20 21
C C C W W C W W N N N N
D0540144
Window = 5
However, when action 13 is completed, the entire window slides five positions to the right,
starting at 18 and ranging to 22:
10 11 12 13 14 15 16 17 18 19 20 21 22
C C C C C C C C N N N N N
D0540146
Window = 5
F.5.6.2 Window in the Flow from Back-Office Applications
Flow from back office

The implementation of the sliding window in the SOAP host adapter enables acknowledgement
messages to be resent if a previously sent acknowledgement is not received, or if a back-office
application resends a message.
If FIFO is used, then Alliance Access waits until all the previous messages are received before it
stores the messages.
Example
• R means a "Received message"

"C" means "Completed",
• "G" means a "Gap"

.
15 July 2011 597

For example, a back-office application sends messages to Alliance Access and the SOAP Host
Adapter uses a window size of 5:
10 11 12 13 14 15 16 17 18 19 20 21
R R R G R R R R
D0540147
Window = 5
The SOAP host adapter receives messages 14 through 17 successfully, but message 13 has
not been received. Therefore, the window does not move to the right. At some point, the back-
office application sends message 13 and the SOAP host adapter sends the appropriate
acknowledgement:
10 11 12 13 14 15 16 17 18 19 20 21 22
R R R R R R R R
D0540148
Window = 5
Put ack
At that moment, the back-office application is still waiting for the acknowledgement of the
message 13. In the worst scenario, if the acknowledgement can be lost, then the back-office
application receives an error which prompts it to re-sends message 13. However, the SOAP
adapter has received and processed message 13, and the window has moved to the right.
Therefore, the SOAP host adapter window expects new messages between 18 and 22, but it
must be ready to accept attempts to resend message 13 through 17.
A retry range must be defined:
10 11 12 13 14 15 16 17 18 19 20 21 22
R R R R R R R R
Window = 5
D0540149
Retry range
Note The retry range and the window usually overlaps.
If the back-office application finally manages to send message 13 and receive an

acknowledgement successfully for it, then the back-office application starts sending messages
18 through 22.

The SOAP host adapter may receive message 19 before message 18, as shown in the
following diagram:
10 11 12 13 14 15 16 17 18 19 20 21 22
R R R R R R R R G R
Window = 5
D0540150
Retry range
The retry range on the SOAP host adapter moves two positions to the right. Since the message
19 got received, you can assume that the back-office application received acknowledgement for
messages 14 and before (otherwise, the back-office application would have sent a message
outside of its own window of 5). In reality, the back-office application received all the
acknowledgement of messages up to 17, but the SOAP host adapter has no way of knowing
this until it receives message 22.
Rules for retry range and window size

The following rules can be defined:
• The retry range spans from the last-received message to W-1 positions on the left:
Retry range = [Last_R-W+1; Last_R]
• The window spans from the first missing message to W-1 positions on the right:
Window = [First_G ; First_G+W-1]
• The full acceptable range for message reception on the SOAP host adapter is the overlap of
these two ranges:
Acceptable range = [Last_R-W+1; First_G+W-1]
where First_G is either the first gap or, if no gap exists, the next message to be received.
The maximum size of the range is twice the window size. The minimal size of the range is the
window size.
F.5.6.3 Window in the Flow towards Back-Office Applications
Flow towards back-office

A similar sliding window mechanism is put in place for the flow of messages from the SOAP
host adapter to the back-office applications. In this flow, the SOAP host adapter sends
messages to the back-office application as replies to the GetAck request sent by the back-
office application.
Example
• R means a "Received message"

S means "Sent message"
• W means a "Waiting acknowledgement"
15 July 2011 599

For example, a SOAP host adapter sends messages to the back-office application the SOAP
Host Adapter uses a window size of 5:
10 11 12 13 14 15 16 17 18 19 20 21
S S S W S S S S
Window = 5
D0540151
On reception of message 13, the back-office application sends an ACK message to
acknowledge the reception of message 13. The SOAP host adapter replies to the back-office
application with another ACK message to inform the back-office application that message 13
has been processed successfully:
10 11 12 13 14 15 16 17 18 19 20 21 22
S S S S S S S S
D0540152
Window = 5
Ack Ack ack
If this ACK message is lost between the SOAP host adapter and the back-office application,
then the back-office application sends a new GetAck request to retrieve message 13. The
SOAP host adapter must accept this retry request even though its window is now 18 to 22. A
retry range is defined.
At that point, the window of the back-office application ranges from 13 to 17, whereas the
window of the SOAP host adapter ranges from 18 to 22.
As a consequence, there must be a retry range between message 13 and 17 because it is
possible that all messages between 13 and 17 have failed for a similar reason:
10 11 12 13 14 15 16 17 18 19 20 21 22
S S S S S S S S
Window = 5
D0540153
Retry range
However, as soon as the SOAP host adapter receives a new GetAck request for message
retrieval, it means that the back-office application received all required information. Therefore,
retries of message 13 are not expected any more, but retries of message 18 are now possible:
10 11 12 13 14 15 16 17 18 19 20 21 22
S S S S S S S S W
Window = 5
D0540154
Retry range

Rules for retry range and window size

The following rules can be defined:
• The retry range spans from the last received message (acknowledged or not) to W-1
positions on the left:
Retry range = [Last_R-W+1; Last_R]
• The window spans from the first non-acknowledged message to W-1 positions on the right:
Window = [First_W ; First_W+W-1]
• The full acceptable range for message retrieval on the SOAP host adapter is the overlap of
these two ranges:
Acceptable range = [Last_R-W+1; First_W+W-1]
where First_W is the first message waiting for acknowledgement or, if none, the next un-
retrieved message.
The maximum size of the range is twice the window size. The minimal size of the range is the
window size.
Note When the sequence number reaches its maximum value (999999), it restarts at 1.
This can lead to scenarios where the window and retry ranges have start values
numerically higher than the end values.
F.5.7 SOAP Message

Structure of a SOAP message
A SOAP message that is exchanged between the back-office applications and Alliance Access
the Alliance Access SOAP host adapter has a common structure, which is presented in the
following figure:
: SOAP Envelope
1 1
: SOAP Header Contains the

Must be present when
Contains the local authentication is
business message
session information enabled (a string or an XMLv2
1 1 document)
0..1 0..1 1
: Alliance Access Header : WS - Security
ity : SOAP Body
D0540155
The different elements of such a SOAP message are:
• SOAP Header (optional):
– Alliance Access Header (soapha:SAAHeader)
– Web Service Security Header (wsse:security)
• SOAP Body (mandatory)
15 July 2011 601

All the SOAP messages generated by invoking the operations exposed by the SOAP host
adapter web service of Alliance Access comply with this structure.
SOAP Header
The following headers are optional parts of a SOAP message:
Header type Description More information
Alliance Access Header contains information specific to the "SAA Header Block -
(soapha:SAAHeader) session opened between the back- soapha:SAAHeader" on
office application and the Alliance page 605
Access SOAP host adapter.
Web Service Security Header provides local authentication at the "Local Authentication of
(wsse:security) level of the SOAP messages SOAP Messages" on
between the back-office application page 602
and the Alliance Access SOAP "Local Authentication -
host adapter. wsse:Security" on
page 605
Soap Body
The mandatory SOAP body: this is the business message itself (MT or XML-based message).
The mandatory SOAP body contains the business message itself: a string or an XMLv2
document. Examples of the SOAP body are provided in "SAA Header Block -
soapha:SAAHeader" on page 605, and in the Knowledge Base Tip 2236509.
F.5.8 Local Authentication of SOAP Messages

Overview
The local authentication between a back-office application and Alliance Access SOAP adapter
is supported using the WS-Security standard (for more information, see OASIS: SOAP Message
Security 1.0).
The Web Service Security Header is a standard block that facilitates the encryption and
authentication of SOAP messages between two applications at the message level, rather than
at transport level.
The Web Service Security Header block contains the local authentication message code
(LMAC) calculated by the application sending the SOAP message. The calculation uses the
HMAC SHA-256 algorithm on a canonicalised version of the SOAP message (the SOAP body
and the SAAHeader block if present) using the Local Authentication key defined within the
message partner in Alliance Access.
For more information about the Web Service Security Header, see "Local Authentication -
wsse:Security" on page 605.
Compliancy requirements
To remain compliant with the WS-Security standards, Application developers must take the
following points into consideration:
• For SOAP, the HMAC algorithm must be performed without truncation. Therefore, the
signature has a size of 256 bits and not 128 bits.

For more information, see WS I: Basic Security Profile 1.0.
• The signature is calculated on the digests of the canonical form of the SOAP body and
header blocks, as described in OASIS: SOAP Message Security 1.0.
F.5.9 XML Structures

Overview
This section defines the XML structures used in the context of the Alliance Access SOAP host
adapter.
F.5.9.1 Namespaces and Algorithms
F.5.9.1.1 Namespace of the SOAP Host Adapter
Description
The URN of the SOAP host adapter namespace.
urn:swift:saa:xsd:soapha
F.5.9.1.2 Namespace Prefixes
Namespace
Namespace URIs represent some application-dependent or context-dependent URI. The choice
of any namespace prefix is not semantically significant. The prefixes used in this document are
selected to refer to the standard schemas.
The following table shows the namespaces and prefixes that are used in this document:
Prefix Namespace Comment
soapha urn:swift:saa:xsd:soapha Elements of the SOAP host adapter
wsse http://docs.oasis-open.org/wss/2004/01/ Web services Security (for more

oasis-200401-wss-wssecurity- information, see OASIS: SOAP
secext-1.0.xsd Message Security 1.0)
wsu http://docs.oasis-open.org/wss/2004/01/ Web services Utility (for more

oasis-200401-wss-wssecurity- information, see OASIS: SOAP
utility-1.0.xsd Message Security 1.0 and "The Attribute
ID" on page 605)
c14n http://www.w3.org/2001/10/xml-exc- Exclusive XML canonicalisation

c14n#
ds http://www.w3.org/2000/09/xmldsig# XML signature Syntax and Processing
soapenv http://schemas.xmlsoap.org/soap/ Elements of the SOAP envelope

envelope
xs http://www.w3.org/2001/XMLSchema XML schema
15 July 2011 603

F.5.9.1.3 Algorithms
Algorithms
These type definitions provide names that represent the algorithm URIs which are used in this
document:
Type Definition Comment
uri-hmac-sha256 string = "http://www.w3.org/2001/04/ Algorithm: HMAC with SHA-256 (see

xmldsig-more#hmac-sha256" HMAC: Keyed-Hashing for Message
Authentication)
uri-sha256 string = "http://www.w3.org/2001/04/ Hashing algorithm SHA-256 (see

xmlenc#sha256" Federal Information Processing
Standards Publications Secure Hash
Algorithm)
uri-xml-exc-c14n string = "http://www.w3.org/2001/10/ XML exclusive canonicalisation C14N

xml-exc-c14n#" (see W3C Recommendation - Exclusive
XML-Canonicalisation version 1.0)
F.5.9.2 SOAP Message - soapenv:Envelope
Tags
Tag Definition Description
soapenv:Envelope soapenv:Header Standard structure of a SOAP message. The

soapenv:Body encoding must be UTF-8.
Although only the tags and the attributes of
SOAP host adapter are documented here, the
message can comprise any other tags and
attributes that comply with SOAP.
soapenv:Header SAAHeader The SAA header (for more information, see

wsse:Security [0..1] "SOAP Message" on page 601) is the header
block required by the SOAP host adapter. It is
interpreted or produced by the SOAP host
adapter.
One optional security header block is present
for local authentication signature (for more
information, see "Local Authentication of
SOAP Messages" on page 602). It is
interpreted or produced by the SOAP host
adapter (the Alliance Access actor).
soapenv:Body attribute { The message body that is required by the

wsu:Id : string [0..1] SOAP host adapter.
}
The attribute Id must be present when the
local authentication is enabled (for more
{ information, see "Namespace of the SOAP
ANY Host Adapter" on page 603).
|| A SOAP fault is never present in a client
request. A SOAP fault is never signed (no
soap:Fault
security header).
}

F.5.9.3 SAA Header Block - soapha:SAAHeader
SAA Header block

The optional SAA Header block contains information specific to the session opened between
the back-office application and the Alliance Access SOAP host adapter.
SAAHeader SessionToken
SequenceNumber [0..1]
ClientRef [0..1]
AckClientRef [0..1]
SessionToken String The session token identifying the session
SequenceNumber Integer The first sequence number that is used by the

SOAP host adapter when sending messages to the
back-office application. The values are in [1,
999999].
ClientRef String The reference the back office uses to identify the
message it will receive from the SOAP adapter
following a GetAck request
AckClientRef String The back-office reference of the previous received

message that it has acknowledged
Example
<SAAHeader xmlns="http://swift.com/saa/soapha" Id="SAAHeader">
<SessionToken>404d4051-3bba-4661-afda-6471cf2b942a</SessionToken>
<SequenceNumber>388</SequenceNumber>
<ClientRef>BOReference020</ClientRef>
<AckClientRef>AckBOReference011</AckClientRef>
</SAAHeader>
F.5.9.4 Local Authentication - wsse:Security
F.5.9.4.1 The Attribute ID
Attribute
If the local authentication is enabled for the message partner indicated in SAAHeader, then the
attribute ID must be present in the body and in each header block comprising the SAAHeader,
The attribute ID can have any value as long as it provides a unique reference in the scope of
the SOAP message.
This attribute belongs to the namespace wsu but is also accepted in the local namespace
(without prefix).
Usage of Attribute ID
To ensure integrity of parts of the message, the URI attribute in ds:Reference must point to the
attribute ID of the part to be authenticated:
Usage of the attribute ID
To ensure integrity of ds:Reference points to Attribute ID of
payload of the message soapenv:Body
15 July 2011 605

To ensure integrity of ds:Reference points to Attribute ID of
session token SAAHeader
message partner name(1) keyInfo
(1) The Message partner name in ds:KeyName determines which LAU key is used to compute the signature
F.5.9.4.2 The Security Header Block of SOAP Host Adapter
Security
The following description is a simplified excerpt from OASIS: SOAP Message Security 1.0
document presenting the settings that are specific to the SOAP host adapter. The security
header block must be built as described in the OASIS: SOAP Message Security 1.0 document.
wsse:Security attribute { The security header block

soapenv:actor:urn:swift:saa contains the XML signature
corresponding to the local
} authentication presented in
ds:Signature "Local Authentication -
wsse:Security" on page 605.
ds:Signature ds:SignedInfo
ds:SignatureValue
ds:KeyInfo
ds:SignedInfo ds:CanonicalizationMethod There must be references for all

ds:SignatureMethod the header blocks and the body.
ds:Reference [2..n]
ds:CanonicalizationMethod attribute { The SOAP host adapter requires

ds:Algorithm : and supports only the C14N
exclusive canonicalisation
uri-xml-exc-c14n method.
} For more information, see W3C
c14n:InclusiveNamespaces Recommendation - Exclusive
XML-Canonicalisation version
1.0.
ds:SignatureMethod attribute { The SOAP host adapter requires

ds:Algorithm : and supports only the HMAC /
SHA 256 signature method.
uri-hmac-sha256
For more information, see
} HMAC: Keyed-Hashing for
Message Authentication.
ds:SignatureValue PCDATA Base64 string The signature is inserted here

encoded in Base64.
ds:KeyInfo ds:KeyName
ds:KeyName String The SOAP host adapter requires

information to identify the key
used for the local authentication.
The id of the message partner
defined in Alliance Access is
provided here.
ds:Reference attribute { The attribute URI refers any part

ds:URI : string of a SOAP message that must
}


ds:Transforms be checked by local
ds:Digestmethod authentication.
ds:DigestValue These can include:
• soapenv:Body
• SAAHeader
• dsKeyInfo
It uses the name provided by the
attribute Id of this header block.
For more information, see "The
Attribute ID" on page 605 and
ds:SignedInfo.
ds:Transforms ds:Transform [1..n]
ds:Transform attribute { The SOAP host adapter requires

ds:Algorithm : and supports only the C14N
exclusive canonicalisation
uri-xml-exc-c14n method.
} For more information, see W3C
c14n:InclusiveNamespaces [0..1] Recommendation - Exclusive
1.0.
ds:DigestMethod attribute { The SOAP host adapter requires

ds:Algorithm : uri-sha256 and supports only the digest
method SHA 256.
}
For more information, see
EMPTY Federal Information Processing
Standards Publications Secure
Hash Algorithm.
ds:DigestValue PCDATA Base64 string The digest is inserted here

encoded in Base64.
c14n:InclusiveNamespaces attribute { For more information, see W3C

c14n:PrefixList : string Recommendation - Exclusive
} 1.0.
F.5.9.5 SOAP Fault - soapenv:Fault
Fault mechanism
The standard SOAP Fault mechanism is used to report error and/or status information to the
calling application.
As per W3C recommendation, the SOAP Fault element appears once as a body entry of the
SOAP response.
The detail tag of the SOAP fault either contains a SAAFault element or a SessionFault element.
These elements have the following structure:
reason string Short text that describes the reason for the error
context string Provides details about the action being performed before
the error occurred
15 July 2011 607

severity string Provides the severity of the error: severe or transient
details string Provides more information on the error and on the

possible resolution actions
F.5.10 SOAP Host Adapter Web Service

Overview
The SOAP Host Adapter Web service gathers the operations that can be invoked to exchange
SOAP messages containing MT, XML-based, or FileAct messages between back-office
applications and Alliance Access.
Operations
The SOAP Host Adapter Web service exposes the following operations:
• Open: open a session
• Close: close a session
• Put: send a message to Alliance Access
• GetAck: request Alliance Access to send a message waiting delivery to the back-office
application and optionally acknowledge a message received from Alliance Access
• Ack: acknowledge a message received from Alliance Access
WSDL and Schema Information

WSDL and schema file location on Windows: %ALLIANCE%\MXS\xsd
WSDL and schema file location on UNIX: $ALLIANCE/MXS/xsd
WSDL file: soapha.wsdl
Schema file: embedded in the soapha WSDL, SAA_XML_v2_0_2.xsd
WSDL get operation: https://hostname:port/soapha?WSDL
Namespace:
• WSDL namespace: urn:swift:saa:wsdl
• SOAP host adapter schema namespace: urn:swift:saa:xsd:soapha
F.5.10.1 Open
Description
This operation requests the opening of a session for the exchange of MT, XML-based, or
FileAct messages using the SOAP host adapter between Alliance Access and back-office
applications.

Input
Open - This element contains the Open element.
Open
Name Type Description Allowed values
MessagePartnerName MessagePartnerN The identity of the

ame message partner defined
in Alliance Access for
which a session will be
opened
SequenceNumberToS SequenceNumber The first sequence [1,999999]

AA number that is used by
the back-office
application when
sending messages to the
SOAP host adapter
WindowSize WindowSize The requested number [1,10]

of messages which can
remain unacknowledged
within an emission or
reception window
FlowDirection Direction The direction of the flow To_MessagePartner

for which a session will From_MessagePartner
be opened
To_And_From_MessagePartn
er
Output
OpenResponse - This element returns the OpenResponse element which contains the
OpenResponseDetails.
OpenResponse
OpenResponseDetails OpenResponseDe
tails
OpenResponseDetails
SequenceNumberFrom SequenceNumber The first sequence [1,999999]

SAA number that will be used
by the SOAP host
adapter when sending
messages to the back-
office application
WindowSize WindowSize The negotiated number [1,10]

of messages which can
remain unacknowledged
within an emission or
reception window
15 July 2011 609

SAAHeader
The SAAHeader returns the session token allocated by Alliance Access. This session token
must be repeated in any subsequent message request being part of this session.
Example
Open request
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:swift:saa:xsd:soapha">
<soapenv:Header />
- <soapenv:Body>
- <urn:Open>
<urn:messagePartnerName>SoapHA</urn:messagePartnerName>
<urn:sequenceNumberToSAA>1</urn:sequenceNumberToSAA>
<urn:windowSize>5</urn:windowSize>
<urn:flowDirection>To_And_From_MessagePartner</urn:flowDirection>
</urn:Open>
</soapenv:Body>
</soapenv:Envelope>
Open response
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<SAAHeader xmlns="urn:swift:saa:xsd:soapha">
<SessionToken>1be691d7-97d5-4a49-8b70-88a63013d447</SessionToken>
</SAAHeader>
</S:Header>
<S:Body>
<OpenResponse xmlns="urn:swift:saa:xsd:soapha">
<openResponseDetails>
<sequenceNumberFromSAA>1</sequenceNumberFromSAA>
<windowSize>5</windowSize>
</openResponseDetails>
</OpenResponse>
</S:Body>
</S:Envelope>
F.5.10.2 Close
Description
This operation requests the closing of a session for the exchange of MT, XML-based, or FileAct
messages using the SOAP host adapter between Alliance Access and back-office applications.
Input
Close - This element contains the empty element Close.
SAAHeader - The SAAHeader contains the session token of the session to be closed by the
Alliance Access SOAP host adapter upon request from the back office.
Output
CloseResponse - This element returns the XMLv2 SessionStatus element as described in
"SessionStatus" on page 501.

Example
Close request
<soapenv:Header>
<urn:SAAHeader Id="SAAHeader">
<urn:SessionToken>1be691d7-97d5-4a49-8b70-88a63013d447</urn:SessionToken>
</urn:SAAHeader>
</soapenv:Header>
<soapenv:Body>
<urn:Close />
</soapenv:Body>
</soapenv:Envelope>
Close response
<S:Body>
<CloseResponse xmlns="urn:swift:saa:xsd:soapha">
xmlns:Sw="urn:swift:snl:ns.Sw" xmlns:SwGbl="urn:swift:snl:ns.SwGbl"
xmlns:SwInt="urn:swift:snl:ns.SwInt" xmlns:SwSec="urn:swift:snl:ns.SwSec">
<Saa:Header>
<Saa:SessionStatus>
<Saa:MessagePartner>SoapHA</Saa:MessagePartner>
<Saa:InputFile />
<Saa:Accepted>1</Saa:Accepted>
<Saa:Rejected>0</Saa:Rejected>
</Saa:Header>
</Saa:DataPDU>
</CloseResponse>
</S:Body>
</S:Envelope>
F.5.10.3 Put
Description
This operation allows a back-office application to send SOAP messages containing MT, XML-
based, or FileAct messages to the Alliance Access SOAP host adapter.
Input
Put - This element contains the XMLv2 Message element as described in "Message" on
page 479.
SAAHeader - The SAAHeader contains the session token of the session being used and the
sequence number associated to the message sent.
Output
PutResponse - This element contains the XMLv2 MessageStatus element as described in
"MessageStatus" on page 500.
sequence number associated to the message sent.
15 July 2011 611

Example
Put request
<soapenv:Header>
<urn:SequenceNumber>1</urn:SequenceNumber>
</urn:SAAHeader>
</soapenv:Header>
<soapenv:Body>
<urn:Put>
<Revision>2.0.2</Revision>
<Header>
<Message>
<MessageIdentifier>fin.999</MessageIdentifier>
<Format>MT</Format>
<Sender>
<BIC12>SAASBEBBAXXX</BIC12>
<FullName>
<X1>SAASBEBBXXX</X1>
</FullName>
</Sender>
<Receiver>
<BIC12>SAATBEBBXXXX</BIC12>
<FullName>
<X1>SAATBEBBXXX</X1>
</FullName>
</Receiver>
<InterfaceInfo>
</InterfaceInfo>
<NetworkInfo>
<FINNetworkInfo />
</NetworkInfo>
<SecurityInfo>
<FINSecurityInfo />
</SecurityInfo>
</Message>
</Header>
<Body>DQo6MjA6VFJOIEZUSTAwMA0KOjc5OlpaWlpaWlpaWlpaWlpaWlpaWlpa</Body>
</DataPDU>
</urn:Put>
</soapenv:Body>
</soapenv:Envelope>
Put response
<S:Header>
<SAAHeader Id="SAAHeader" xmlns="urn:swift:saa:xsd:soapha">
</SAAHeader>
</S:Header>
<S:Body>
<PutResponse xmlns="urn:swift:saa:xsd:soapha">
<Saa:Revision>2.0.2</Saa:Revision>
<Saa:Header>
<Saa:MessageStatus>

</Saa:Header>
</Saa:DataPDU>
</PutResponse>
</S:Body>
</S:Envelope>
F.5.10.4 GetAck
Description
This operation allows a back-office application to request, from the Alliance Access SOAP host
adapter, MT, XML-based, or FileAct messages that are waiting for delivery in the exit point
associated to the Alliance Access message partner. It also acknowledges the reception of the
messages sent by Alliance Access.
Input
GetAck - This element contains a time-out after which Alliance Access replies that no
messages are to be returned to the application.
GetAck
Timeout Timeout Between 1 and 100

seconds inclusive
SAAHeader - The SAAHeader contains the session token of the session being used, the
reference the back-office associates to the message it receives, the reference of the message
for which it acknowledges reception (for more information, see "SOAP Message -
soapenv:Envelope" on page 604).
Output
GetAckResponse - This element contains an XMLv2 element whose type depends on the
message retrieved from the exit point:
GetAckResponse
XMLv2 Element Type of retrieved message Document Reference
TransmissionReport Transmission notification "TransmissionReport" on page 495
DeliveryReport Delivery notification reconciled with "DeliveryReport" on page 499

the original message
HistoryReport History or information notification "HistoryReport" on page 493
DeliveryNotification Delivery notification "DeliveryNotification" on page 497
Message Message sent from Alliance Access "Message" on page 479

to the back-office application
If there is no message to be retrieved, then the SAAHeader does not include any sequence
number.
sequence number used by Alliance Access to identify the message.
15 July 2011 613

Example
GetAck request
<soapenv:Header>
<urn:ClientRef>REF1</urn:ClientRef>
</urn:SAAHeader>
</soapenv:Header>
<soapenv:Body>
<urn:GetAck />
</soapenv:Body>
</soapenv:Envelope>
GetAck response with a Message as XMLv2 element.

<S:Header>
<ClientRef>REF1</ClientRef>
</SAAHeader>
</S:Header>
<S:Body>
<GetAckResponse xmlns="urn:swift:saa:xsd:soapha">
<Saa:Revision>2.0.2</Saa:Revision>
<Saa:Header>
<Saa:Message>
<Saa:SubFormat>Input</Saa:SubFormat>
<Saa:Sender>
<Saa:BIC12>SAASBEBBAXXX</Saa:BIC12>
<Saa:FullName>
</Saa:FullName>
</Saa:Sender>
<Saa:Receiver>
<Saa:BIC12>SAATBEBBXXXX</Saa:BIC12>
<Saa:FullName>
</Saa:FullName>
</Saa:Receiver>
<Saa:InterfaceInfo>
<Saa:MessageNature>Text</Saa:MessageNature>
<Saa:NetworkInfo>
<Saa:IsNotificationRequested>false</Saa:IsNotificationRequested>
<Saa:Network>Application</Saa:Network>
<Saa:CorrespondentInputTime>20081203122109</Saa:CorrespondentInputTime>

</Saa:NetworkInfo>
</Saa:Message>
</Saa:Header>
<Saa:Body>DQo6MjA6VFJOIEZUSTAwMA0KOjc5OlpaWlpaWlpaWlpaWlpaWlpaWlpa</
Saa:Body>
</Saa:DataPDU>
</GetAckResponse>
</S:Body>
</S:Envelope>
F.5.10.5 Ack
Description
This operation allows a back-office application to acknowledge the last message it received
from the Alliance Access SOAP host adapter.
Input
Ack - Empty
SAAHeader - The SAAHeader contains the session token of the session being used, the
reference of the message for which it acknowledges reception. For more information, see "SAA
Header Block - soapha:SAAHeader" on page 605.
Output
AckResponse - Empty
SAAHeader - The SAAHeader contains the session token of the session being used.
Example
Ack request
<soapenv:Header>
<urn:AckClientRef>REF1</urn:AckClientRef>
</urn:SAAHeader>
</soapenv:Header>
<soapenv:Body>
<urn:Ack />
</soapenv:Body>
</soapenv:Envelope>
Ack response
<S:Header>
<AckClientRef>REF1</AckClientRef>
</SAAHeader>
</S:Header>
<S:Body>
<AckResponse xmlns="urn:swift:saa:xsd:soapha" />
</S:Body>
</S:Envelope>
15 July 2011 615

F.6 WebSphere MQ
Overview
The WebSphere MQ method enables files and SWIFT messages to be exchanged between
Alliance Access and back-office applications through IBM WebSphere MQ. The WebSphere MQ
connection method requires the licence package 13:MQ HOST ADAPTER.
The WebSphere MQ connection method supports the following data formats:
• MQ-MT
• XML version 2 with revision 1, 2, or 3
F.6.1 Configuration of WebSphere MQ

Overview
Before you use the WebSphere MQ Host Adapter in Alliance Access, you may have to define
the environment variables as described in this section. This will depend on how you have
configured you IBM WebSphere MQ software, and where it is installed.
If none of these environment variables are set, then default locations are searched.
F.6.1.1 Installation Directory for WebSphere MQ
WebSphere MQ on UNIX platforms

On UNIX, the following table provides the default directory where IBM WebSphere MQ is
installed on the Alliance Access machine:
Platform Default location
AIX /usr/mqm/lib
Oracle Solaris /opt/mqm/lib
If the WebSphere MQ software is not installed in the default directory, then you must add the
following line to the Alliance Access instance file, .swa.$ALLIANCE_INSTANCE.rc:
Platform Line to add to the instance file
AIX export LIBPATH=$LIBPATH:/filesys1/mqm/lib
Oracle Solaris LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/filesys1/mqm/lib
The following conditions apply for the UNIX platform:
• /filesys1/mqm/lib is a directory containing the WebSphere MQ library
• The Alliance Access instance file is located in the home directory of the Alliance Access
Administrator ($ALLIANCE_INSTANCE is the environment variable describing the name of
the Alliance Access instance). This file is a hidden file.
WebSphere MQ on Windows platform

On Windows, ensure that the IBM WebSphere MQ environment variables are defined in the
System Properties (Advanced tab) in the Control Panel.

F.6.1.2 Connection to WebSphere MQ Client
Purpose
There are two ways to implement the WebSphere MQ Host Adapter as a WebSphere MQ client:
• define the location of the WebSphere MQ Queue Manager using an environment variable,
MQSERVER
• install a WebSphere MQ channel table, using two environment variables, MQCHLTAB and
MQCHLLIB
Location of the WebSphere MQ Queue Manager

The easiest way to implement a WebSphere client is to define the environment variable,
MQSERVER.
The value of MQSERVER contains the TCP/IP and WebSphere MQ parameters that are
required for the connection to the WebSphere MQ Queue Manager:
Platform Action to take
UNIX Add the following line to the Alliance Access instance

file .swa.$ALLIANCE_INSTANCE.rc:
export MQSERVER=CHANCLI/TCP/'111.222.333.444(1414)'
Windows Define an environment variable in the System Properties (Advanced tab) in the
Control Panel:
• Variable name: MQSERVER
• Variable value: CHANCLI/TCP/111.222.333.444(1414)
Using this environment variable limits access to a single WebSphere MQ Queue Manager. For
more information about the MQSERVER variable, see the information about using IBM
WebSphere MQ environment variables in the WebSphere MQ documentation about clients.
WebSphere MQ Channel Table

The second way to implement a WebSphere client is to install a WebSphere MQ channel table
on the Alliance Access machine. The channel table describes all the WebSphere MQ channels
that can be used to reach different WebSphere MQ Queue Managers.
In this case, the following two environment variables must be defined:
• MQCHLTAB defines the file name where channels are described.
• MQCHLLIB defines the directory where the channel file is located.

For example:
UNIX Add the following lines to the Alliance Access instance

file .swa.$ALLIANCE_INSTANCE.rc:
export MQCHLTAB=/AMQCLCHL.TAB
export MQCHLLIB=/mqchllib
15 July 2011 617

Windows Define the environment variables in the System Properties (Advanced tab) in
the Control Panel:
• Variable name: MQCHLTAB

Variable value: AMQCLCHL.TAB
• Variable name: MQCHLLIB

Variable value: C:\MQCHLLIB
F.6.2 WebSphere MQ Concepts

Introduction
WebSphere MQ is a communications system that provides asynchronous delivery of data
across a broad range of hardware and software platforms.
This section provides a brief overview of the four fundamental concepts in WebSphere MQ:
• messages
• queues
• queue managers
• channels
For more information about WebSphere MQ, see the WebSphere MQ documentation.
F.6.2.1 WebSphere MQ Messages
Definition
Applications use messages to exchange data. A WebSphere MQ message is a string of bytes
that has a meaning for the applications that use it. The applications can be running on the same
platform, or on different platforms.
A physical MQ message is the smallest unit of information that can be placed on or removed
from a queue. A WebSphere MQ message has two parts:
• header (also called message descriptor)
• application data (the payload)

The message descriptor identifies the message and contains control information. The Alliance
Access defines the structure of the application data.

Logical MQ messages
If the payload of the message is extremely large, then it can be split across several messages.
WebSphere MQ can group several physical messages together into a group of logical
messages or it can segment the physical message into several file chunks and group them into
one logical message. The distribution depends on the functionality support by the applications.
With a large message is segmented, each physical message in the group has the same Group
Identifier and Message Sequence Number (GroupID and MsgSeqNumber) in their Message
Descriptor parts. However, the Message identifier and Offset values (MsgId, and Offset) in their
Message Descriptor parts differ.
The following diagram shows a file that is segmented and grouped into two logical messages:
Segment
XMLv2 File Chunk File Chunk ...
D0540194
Logical Message (seq#1) Logical Message (seq#2)
With a large message is not segmented and is only grouped, then each physical message in the
group has the same Group Identifier (GroupID) in their Message Descriptor parts.
The following diagram shows a file that is not segmented but is grouped into several logical
messages:
Segment
XMLv2 File Chunk File Chunk ...
D0540195
Logical Message (seq#1) Logical Message (seq#n)
For more information about the components of an MQ message, see the WebSphere MQ
documentation.
F.6.2.2 WebSphere MQ Queues
Definition
A WebSphere MQ queue is a data structure in which messages are stored. The messages may
be put on or retrieved from the queue by applications. Queues exist independently of the
applications that use them.
15 July 2011 619

F.6.2.3 Queue Managers and MQI Channels
Queue manager
A WebSphere MQ queue manager is an entity that provides queue-based services to
applications, and manages the queues that belong to it. Such queues are referred to as local
queues for that queue manager. The queue manager ensures that messages are put on the
correct queue, as requested by the application. Every queue belongs to a single queue
manager. The same queue name can exist in different queue managers.
Applications put messages on and get messages from queues. For that purpose, applications
must connect to a queue manager that is said to be a local queue manager for that application.
In a simple configuration, a single queue manager is created and local queues are defined on
this queue manager. Applications can then connect to this queue manager and can use its
queues to exchange messages.
MQI channel
An application connects to a queue manager through an MQI channel. An MQI channel is bi-
directional, it must be created as a Server-connection Channel on the queue manager (see
the WebSphere MQ Clients documentation).
F.6.2.4 Remote Queue Managers and Message Channels
About remote queue managers

An application can get messages only from the local queues of a local queue manager.
However, an application can put a message in a queue managed by a queue manager to which
it is not directly connected. Such a queue manager is a remote queue manager for that
application and the queues are said to be remote queues. An application addresses a queue by
specifying its queue name and the name of the queue manager that manages that queue.
About message channels

A message channel (not to be confused with an MQI channel) provides a communication path
between two queue managers. The message channel is used to transmit messages from one
queue manager to another, and shields the application programs from the complexities of the
underlying networking protocols. A message channel can transmit messages in one direction
only. Two message channels are required if you required bi-directional communication between
two queue managers. The configuration of message channels is out of the scope of this
document. For more information, see the WebSphere MQ documentation.
Note Do not confuse the concept of local and remote queue managers with that of a
local or remote physical location. For example, you can have a local queue
manager that connect to an application by an MQI channel while the application
and the queue managers reside on different systems.
F.6.2.5 Application Connectivity
Specification requirements
Applications may connect directly to several local queue managers, by establishing several MQI
channels. When an application tries to establish a connection to a queue, it must specify the
queue address and the MQI channel to a local queue manager through which the queue is
reached. The queue address consists of the queue name and queue manager name.

F.6.2.6 WebSphere MQ Concept Summary
Illustration of concepts
The following diagram provides an overview of the fundamental WebSphere MQ concepts:
Application 1
(e.g. MQ Host Adapter)
MQI
Channels
QM1 QM2
Application 2
Q11 Q12 Q21
Message Channel
QM3
Q31
Application 3
D0340038
Note The concept queue managers shown in the graphic are abbreviated for simplicity,
for example, QM1, QM2, and QM3.
Local and remote queue managers

QM1 is a local queue manager for Application 1.
QM2 is a local queue manager for Application 1 and Application 2.
QM3 is a local queue manager for Application 3 and a remote queue manager for Application
1.
Local and remote queues

Q11 and Q12 are local queues of QM1.
Q21 is a local queue of QM2.
Q31 is a local queue of QM3, but also a remote queue for QM1.
15 July 2011 621

Client channels and message channels

Application 1 is connected directly to QM1 and QM2 by two MQI channels.
Application 2 is connected directly to QM2 with one MQI channel.
Application 3 is connected directly to QM3 with one MQI channel.
QM1 can transmit messages to QM3 using the message channel.
Application 1 can put messages on Q31 of QM3 using its MQI channel to QM1.
F.6.3 Structure of a WebSphere MQ Message

Description
Alliance Access supports the following types of WebSphere MQ messages:
• Datagram (MQMT_DATAGRAM)
• Request (MQMT_REQUEST)
• Report (MQMT_REPORT), a response message for an MQMT_DATAGRAM
• Reply (MQMT_REPLY), a response message for an MQMT_REQUEST
WebSphere MQ message
The following diagram shows the structure of a WebSphere MQ message:
Message
Message data
descriptor
Elements in an MQ Message D0540135
The following table describes the parts in an MQ message that Alliance Access interprets to
process the message successfully. The elements that Alliance Access requires are marked as
Mandatory (M). If an element is marked optional (O), and has a non-null value, then Alliance
Access processes it appropriately:
Description of the elements
Part Description From (1) To (2) To

(Resp)
(3)
MQMessageDescript Contains the WebSphere MQ-defined fields. M M M

or The following sections outline the fields that
Alliance Access can modify in the MQ
Descriptor.
See "MQ Message Descriptor" on page 623.

Part Description From (1) To (2) To

(Resp)
(3)
MQMessageData Contains the message that is being exchanged M M O

between applications.
The message data part is sent in one of the
following transport formats:
• MQ-MT (MQ-MT message)

See "MQ-MT Format" on page 534.
• XML version 2 (DataPDU)

See "XML Format 2" on page 471.
(1) Represents a message request that Alliance Access receives from a message partner.
(2) Represents a notification, a system message, or a message request that Alliance Access sends to a message
partner.
(3) Represents a response message request that Alliance Access sends to a message partner.
F.6.4 MQ Message Descriptor

Introduction
This section describes the elements that are included in the MQ Message Descriptor when it is
included in the following messages:
• Message Request, that Alliance Access receives from a message partner through
WebSphere MQ
• Message Response, that Alliance Access sends to WebSphere MQ, if it is requested
• Message Request, that Alliance Access sends to a message partner through WebSphere
MQ
• Notification message or a System message, that Alliance Access sends to a message

partner through WebSphere MQ, if it is requested.
Note This section describes the elements in the MQ Descriptor that Alliance Access
interprets when it processes an MQ message. It does not describe all the elements
of the MQ Descriptor. The elements that Alliance Access requires are marked as
Mandatory (M). If an element is marked Optional (O) and has a non-null value, then
Alliance Access processes it.
For more information about the elements in the MQ Descriptor, see the IBM
WebSphere MQ Application Programming Reference.
F.6.4.1 Message Request from WebSphere MQ to Alliance Access
Message Request
In this section, a message request is an MT or MX message that a back-office application sends
to Alliance Access through WebSphere MQ.
15 July 2011 623

The elements in the MQ Message Descriptor have the following values when they are included
in a message request from a back-office application:
Elements in MQMessageDescriptor
Element Description Mandatory?
MsgType The type of message, which is one of the following: M
• Request (MQMT_REQUEST), which requires a response from

Alliance Access
• Datagram (MQMT_DATAGRAM), which does not require a

response from Alliance Access
Report This element is present if an application requires a report O

message, regarding one of the following:
• a report about the success of actions that relate to the

original message
• the action to take when processing the MsgID or CorrelID in

the message
Alliance Access can interpret the following values(1) in the

Report element:
MQRO_PAN
MQRO_NAN
MQRO_NEW_MSG_ID
MQRO_PASS_MSG_ID
MQRO_COPY_MSG_ID_TO_CORREL_ID
MQRO_PASS_CORREL_ID
CodedCharSetID The Coded Character Set ID (CCSID) which is the character M

set identifier of data in the message.
Alliance Access converts a message request to one of these
character sets after it reads it from a queue:
• ASCII, for MQ-MT format
• UTF8, for XML version 2
Format A code that an application uses to indicate the nature of the M

data in the message.
Alliance Access can interpret the following values(2) in the
Format element:
MQFMT_STRING
MQFMT_NONE
MQFMT_MD_EXTENSION
MQFMT_REF_MSG_HEADER
MQFMT_DEAD_LETTER_HEADER
MQFMT_IMS
MQFMT_IMS_VAR_STRING
MsgId A message identifier which an application uses to distinguish O

one message from another.
Present if the application requires a response for the message.
ReplyToQ The name of the queue to which Alliance Access sends the O
requested report.

Element Description Mandatory?

Present if the MsgType is "MQMT_REQUEST".
ReplyToQMgr The Queue Manager, which is the owner of the ReplyToQ O

queue.
Present if the MsgType is "MQMT_REQUEST".
Priority The priority that WebSphere MQ assigns to the message M
CorrelID The correlation identifier O
BackoutCount A count that WebSphere MQ uses to detect errors that arise M

from processing. The queue manager fills this field
automatically.
If this field is not "0", then Alliance Access sets the Possible
Duplicate Emission flag of the message to "true".
(1) For information about how Alliance Access uses these values, see "Message Response to WebSphere MQ" on
page 625. You can find a detailed description of these values in the IBM WebSphere MQ Application
Programming Reference.
(2) You can find a detailed description of these values in the IBM WebSphere MQ Application Programming
Reference.
F.6.4.2 Message Response to WebSphere MQ
Overview
You can reconcile WebSphere MQ messages using the report message feature of WebSphere
MQ. The report message (either a Report or a Reply) provides information about the initial
processing that Alliance Access has performed on the message. The report message provides
the Alliance Access instance that processed the message, the UUMID, and error validation
information.
An application can request a report for a message optionally, by including a Report element in
the MQ Message Descriptor part of the message. The Report element can also specify how to
set the message and correlation identifiers in the report message.
If an application requests a report message and if one of the following conditions are met, then
Alliance Access creates a Message Response for the message:
• The MsgType of the original message is "Datagram" and MQ requested either a PAN or a
NAN report for the message.
• The MsgType of the original message is "Request".

If Alliance Access creates a Message Response, then it sends it to the Queue and Queue
Manager that are specified in the original Message Request.
15 July 2011 625

in a message response, which Alliance Access sends to WebSphere MQ:
Element Description Availability
MsgType The type of message response, which is one of the following: M
• Report (MQMT_REPORT), if the original message was a

Datagram
• Reply MQMT_REPLY, if the original message was a Request.
Feedback This field indicates whether an error was reported during the M
processing of the MQ Message Data.
If no error is reported, then a PAN message is sent with value
MQFB_PAN.
If an error is reported, then a NAN message is sent with one
of values outlined in the section, see "Feedback options for
NAN" on page 627.
CodedCharSetID The Coded Character Set ID (CCSID) which is the character M

set identifier of data in the message.
Alliance Access converts a message request to one of these
character sets after it reads it from a queue:
Format A code that an application uses to indicate the nature of the M

data in the message.
Alliance Access uses the format, MQFMT_STRING for a
response message.
MsgId If the Report field of the original message contained M

"MQRO_NEW_MSG_ID", then the MsgID of the message
response is the SUMID + the Instance Number of the original
message.
If the Report field of the original message contained
"MQRO_PASS_MSG_ID", then the MsgID of the message
response is the same as the MsgId of the original message.
Priority The priority of the Message response is the same as the M

priority of the original message.
CorrelID If the Report field of the original message contained M

"MQRO_COPY_MSG_ID_TO_CORREL_ID", then the
CorrelID of the message response is the same as the MsgID
of this response message.
If the Report field of the original message contained
"MQRO_PASS_CORREL_ID", then the CorrelID of the
message response is the same as the MsgID of the original
message.
AccountingToken The value of the Unit element of the original message. This O
allows an application to track the cost associated with
processing the message.
Present if Transfer SAA Information and Use MQ
Descriptor are both selected in the message partner profile.

ApplIdentityData Information about the originator of the message. O

<SAA instance name>/(<Queue name>|Completed]) where
<Queue name> is the queue in which the message is stored
in Alliance Access.
Present if Transfer SAA Info and Use MQ Descriptor are
both selected in the message partner profile.
PutApplName The name of the process Alliance Access process for the MQ M
Interface ("MXS_ha")
The Queue manager fills this field automatically.
UserIdentifier The name of the operating system user that owns the Alliance O
Access instance.
Descriptor are both selected in the message partner profile.
Feedback options for NAN

The Feedback field in the MQ Message Descriptor indicates whether an error was reported
during the processing of the MQ Message Data.
The value of the Feedback field depends on the message validation level that was requested in
the message. If no validation was configured, then the feedback is always positive.
Feedback value MQ code for Feedback Description
FB_MSG_NOTVALIDATED MQFB_APPL_FIRST + 1 The message failed validation
FB_MSG_NOTROUTED MQFB_APPL_FIRST + 2 The routing of the message failed.
F.6.4.3 Request from Alliance Access to WebSphere MQ
Message request
In this section, a message request is an MT or an MX message that Alliance Access sends to a
in a request, which Alliance Access sends to WebSphere MQ:
Element Value Availability
MsgType The type of message, which is a MQMT_DATAGRAM M
CodedCharSetID The Coded Character Set ID (CCSID) which is the M

character set identifier of data in the message.
Alliance Access converts a message request to one of
these character sets after it reads it from a queue:
Format A code that an application uses to indicate the nature of M

the data in the message.
15 July 2011 627

Element Value Availability

Alliance Access uses the format, MQFMT_STRING.
MsgId SUMID (16 bytes) M
Priority The Alliance Access priority of the message instance, M

mapped to the WebSphere scale of priorities.
AccountingToken The value of the Unit element of the original message. O

This allows an application to track the cost associated
with processing the message.
Descriptor are both selected in the message partner
profile.

<SAA instance name>/(<Queue name>|Completed])
where <Queue name> is the queue in which the
message is stored in Alliance Access.
profile.
PutApplName The name of the process Alliance Access process for M

the MQ Interface ("MXS_ha")
UserIdentifier The name of the operating system user that owns the O
Alliance Access instance.
profile.
F.6.4.4 Notification or System Message to WebSphere MQ
Overview
This section describes the elements that Alliance Access interprets in the MQ descriptor of
notification messages and system messages.
Notification messages include Transmission, Delivery, Information, and History messages that
Alliance Access creates from additional instances of a message, based on the results of
message reconciliation.
A System message is a Delivery Notification that Alliance Access receives from the SWIFT
network to provide status about the delivery of a message.
Transmission notification
A Transmission notification is a message representing the result of the transmission to the
SWIFT network. SWIFT performs full syntax and semantic checks before it returns an
acknowledgement (ACK). Other checks, such as validity of the sender and the receiver, are also
performed. The checks can cause a message to be rejected and a negative acknowledgement
(NAK) is returned in response.
Delivery Notification
A Delivery Notification is a message that provides status about the progress of message
processing. Alliance Access receives delivery notification messages, which can be reconciled
with the original message through a reference in the CorrelId field. You can also append the
text of the original message to the Delivery Notification message.

Information notification
An information notification (also called an intervention) is a message that the Routing
application in Alliance Access creates to show details about the result of routing or processing.
History notification
A history notification is a list of information notification that the Routing application in Alliance
Access creates to provide an overview of the processing that Alliance Access performed on a
message.
System message
To provide information about the delivery of a message, Alliance Access receives a Delivery
Notification from SWIFTNet, which is of the following:
• MT messages: an MT 010, MT 011, MT 012, MT 015, or MT 019.
• MX or FpML messages: a response, that is, not a message.

When Alliance Access receives a Delivery Notification from SWIFTNet, it creates an original
message instance for the Delivery Notification. If an application has requested a Delivery
Notification for a message request, then Alliance Access sends the message instance for this
Delivery Notification message to the application as a System Delivery Notification message.
Note As a result of reconciling the Delivery Notification from SWIFTNet, Alliance Access
can create an additional message instance (of type Delivery Notification) for the
message request instance. In this case, a Delivery Notification and System
Delivery Notification message can exist for one message request. Since the priority
of a System Message is higher than a notification message, Alliance Access may
send a System Delivery Notification message to an application before it transmits a
Transmission notification.
in a notification or a system message, which Alliance Access sends to WebSphere MQ:
MsgType The type of message, which is a MQMT_DATAGRAM M
CodedCharSetID The Coded Character Set ID (CCSID) which is the M

character set identifier of data in the message.
Alliance Access converts a message request to one of
these character sets after it reads it from a queue:
Format A code that an application uses to indicate the nature of M

the data in the message.
Alliance Access uses the format, MQFMT_STRING .
MsgId SUMID (16 bytes) M
Priority The value "10" less the priority in the original message. M
15 July 2011 629

CorrelID For a Transmission or and a Delivery notification M

message, the CorrelID is the same as the MsgId of the
original message request.
For an Information notification, a History notification, or a
system message, the CorrelID is the SUMID.
AccountingToken The value of the Unit element of the original message. O

This allows an application to track the cost associated
with processing the message.
profile.

<SAA instance name>/(<Queue name> where <Queue
name> is the name of the exit point from where the
message was processed by a message partner.
profile.
PutApplName The name of the process Alliance Access process for M

the MQ Interface ("MXS_ha")
UserIdentifier The name of the operating system user that owns the O
Alliance Access instance.
profile.
F.6.5 FileAct over WebSphere MQ

Purpose
The WebSphere Host Adapter allows the FileAct messages to use the same queues as the
other message flows. This makes Alliance Access easier to integrate with back-office
applications, and allows several instances of Alliance Access to read from the same MQ queue.
To achieve this, you must select Full FileAct mode in the Message Partner profile.
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 between the back-office application and Alliance Access over WebSphere MQ.
• Mixed FileAct mode - where the XMLv2 message is transferred between the back-office
application and Alliance Access over WebSphere MQ, and the FileAct payload is transferred
over the local file system. This is similar to the File Transfer connection method.
Full FileAct mode

When the WebSphere Host Adapter is operating in Full FileAct Mode, it transfer messages or
files over FileAct using two MQ messages:
• MQ message containing the FileAct settings in the XML version 2 format

This MQ message is associated with the MQ message that carries the payload.
• MQ message containing the file payload

If the payload is greater than the configured maximum size of a message at the queue manager
or channel (Chunk Size ) then the payload can be grouped or segmented into several MQ
messages. For more information about calculating the Chunk Size, see "Calculation of Chunk
Size" on page 631.
The MQ Host Adapter does not enforce the usage of message segmentation. The MQ Host
Adapter supports the case where the FileAct payload is split into multiple logical messages that
are part of the same group. In this case, the first logical message must be the XMLv2 message,
and the other logical messages are the different chunks of the FileAct payload. For more
information, see "WebSphere MQ Messages" on page 618.
The following outlines the segmentation and grouping that the WebSphere Host Adapter
supports:
Direction MQ Host Adapter supports Limitation
Input from back-office application any combination of both grouping The first logical message must
and segmentation not be segmented and must be
the XMLv2 message.
Output to the back-office either segmentation or message This depends on the value of
application grouping Don't use Segmentation and
Chunk Size parameters in the
message partner profile.
Calculation of Chunk Size

Ensure that both Alliance Access and the back-office application can the chunk sizes effectively.
For example, you can use the following formula to determine an effective value for Chunk Size:
MAX_FileAct_Size / Chunk Size > MAX_Uncommitted message - 1
where:
• MAX_FileAct_Size is the maximum FileAct payload size being exchanged.

The default is 250 Mb.
• Chunk size is the size of each chunk (default at SAA side is 32 Kb).
• MAX_Uncommitted message is the number of messages that a transaction can hold. You
can configure this at the Queue manager side, and the default is 10,000.
1 is deducted because the XMLv2 message is always included before the chunks.
F.6.6 Management of a WebSphere MQ Session

Introduction
This section describes how Alliance Access recovers sessions with the MQ Host Adapter.
F.6.6.1 Recovery of a WebSphere MQ Connection
Overview
If the Keep Session Open option is selected in the message partner profile and a session
connection is lost, then the session status changes to "Interrupted" and Alliance Access
attempts to re-establish the connection to WebSphere MQ.
15 July 2011 631

If the Keep Session Open option is not selected and a session connection is lost, then the
session status changes to "Closed".
Recovery attempts
System parameters specify the frequency of the recovery attempts, as follows:
1. After the number of seconds that are specified in Recovery Time - Initial have elapsed,
then Alliance Access attempts to re-open the session for the first time.
2. If the reconnection is unsuccessful, then Alliance Access increases the time between the
reconnection attempts by the value specified in Recovery Time - Increment, and attempts
to re-establish the connection.
3. The time interval between attempts is increased after every attempt until it reaches the
value specified in Recovery Time - Max, after which Alliance Access attempts the
reconnection at these intervals.
Recovery of a Full FileAct session

Alliance Access uses the WebSphere options, MQ MQGMO_ALL_MSGS_AVAILABLE and
MQGMO_ALL_SEGMENTS_AVAILABLE. This ensures that Alliance Access processes a
message only after all the segments and messages of the logical message are in the queue. If a
segment is missing, then the Alliance Access does not process the logical message.
If Alliance Access exits unexpectedly while processing a message or segment, then the action
can be recovered and all the messages that Alliance Access processed are rolled back and
placed in the MQ queue again. The "Backout count" of these rolled-back messages are
incremented and Alliance Access treats them as a Possible Duplicate the next time that it
processes them.
When sending a FileAct message over WebSphere MQ, Alliance Access only routes the FileAct
instance when the complete message has been sent to the back-office application.
After the message is sent,Alliance Access cannot know whether a segment is lost during its
transfer. It is the responsibility of the WebSphere MQ infrastructure to ensure that no messages
are lost. The application reading the FileAct messages can use the same set of options as
Alliance Access to process messages only after all segments are present in the queue.
F.6.6.2 Closure of an MQ Session
Automatic sessions
If you close an automatic session for an incoming message partner (that is, with From Message
Partner as the Allowed direction) or for an outgoing message partner (that is, with To
Message Partner as the Allowed direction), then Alliance Access re-opens the session
automatically. To avoid this session reopening, you must first disable the message partner and
afterwards close the session.
Manual sessions
You can stop a manual session of either an incoming or outgoing message partner.

Appendix G - Parameter Files in AI
Appendix G
Parameter Files in AI
Overview
This section describes the parameter files that are used with the File Transfer connection
method.
G.1 Creating an Input Parameter File

Purpose
A parameter file contains security, routing, formatting, and processing information for the
exchange of files using the File Transfer connection method. For file transfer from a message
partner (input), you must provide a parameter file. The parameter file is created automatically for
files that are transferred to a message partner (output).
Filename and location

You can create a parameter file in a text editor, and store it in the directory that specified in the
Input/Output Filename Pattern field of the message partner profile. A parameter file must
contain text only and have a file extension of .par
Structure
A parameter file has two sections:
• header section - contains general information about the communication request
• data section - contains processing information

Each section contains lines of text, and each line represents a parameter. A parameter consists
of a tag identifier and a parameter value, separated by two colons.
The tags syntax have the following syntax:
• The tag 050000 indicates the start of a section.
• The tag 050999 indicates the end of a section.
• A tag identifier must be the first six characters on the line.
• Two colons must immediately follow the tag identifier.
• The field after the colons is used for the actual value.
• There must be no leading spaces in the value.

For example, the valid syntax for a parameter is: 000010::MSG
15 July 2011 633

Parameter descriptions
The input parameter file can have the parameters that are described in the following table. In
the table, "x" represents the number of characters that the value may have. All printable
characters are accepted:
Description Parameter tag Value field Optional /

field limits Mandatory
Name of the interface 000010 3x M
Sending application name 000011 26x M
Receiving application name 000012 26x M
Application Transaction Reference 000100 10x M
Communication request type: 000102 1x M
• I - input from a message partner
• Ooutput to a message partner
Date and time of creation 000161 date_time M

Format: YYMMDDHHMMSS
Start of data section 050000 no value M

required
Name of message file 050313 60x M
The path to the directory where the message file is 050314 60x M(1)
stored before it is transferred O(2)
Path name in the Remote Application Environment 050315 60x O
Result of Local Authentication on part of the 050510 16x O

parameter file
CRC calculation of the message file 050520 12x M
End of data section 050999 no value M

required
(1) Mandatory for Automatic input from a message partner.
(2) Optional for Manual input from a message partner. You can omit this tag if you include 050315 instead.
G.2 Authenticating Input Parameter Files

Overview
Parameter files are authenticated during input. Alliance Access validates the following fields for
the correct data
In the following table, the brackets, <...>, represent a variable that is validated. A description
of the variable is given within the brackets:
Tag field Value of the field
000010 MSG
000011 <name of the message partner profile>
000012 AllianceMXS<name of the message partner profile>

Appendix G - Parameter Files in AI
Tag field Value of the field
000102 I
050313 <name of the message file>
050314 <The path to the directory where the message file is stored before it
is transferred from a message partner>
050520 <CRC value of the message file>

During authentication, a CRC check is made on the message file using the CRC16-
CCiTT algorithm. If the value in this field does not match the result of the CRC
check, then the file is rejected.
G.3 Specifying the Parameter File in the Message

Partner Profile
Overview
The Application Interface is used to specify that a parameter file is required in the message
partner profile.
Specifying the parameter file in the message partner profile:
1. Run the Application Interface application.
2. Double-click your selected message partner in the main window. The message partner
profile tabs appear.
3. Select Disable from the Message Partner menu.
4. Select Required in the Parameter file field.
5. Specify the location of the parameter file in the Input/Output Path field:
– If the session direction is To Message Partner, then the parameter file is generated and
copied to this directory automatically. You can specify the output file extension.
– If the session direction is From Message Partner, then an existing parameter file must
be present (if required).
6. Select Modify from the Message Partner menu to save your changes.
7. Select Enable from the Message Partner menu. The message partner profile is now ready
for exchange sessions.
15 July 2011 635

Appendix H
Transmission and Delivery of FINCopy Messages

Introduction
PKI signing is used for authentication, and authorisation is done using the Relationship
Management Application. Authorisation can be bypassed for the FINCopy service, as described
in "FINCopy Service" on page 636.
H.1 FINCopy Service

Overview
In its default operating mode - Y Copy - a full or partial copy of the message is delivered to the
Central Institution Destination within an MT 096 "Copy Container Message", or "settlement
request". This message is authenticated by the central institution, using the PAC trailer
computed by the sender and delivered with the message. The sender will have calculated the
PAC using the SA-2 algorithm. The central institution receives the message with both the MAC
and the PAC inserted into the trailer block.
Before authorising the message and sending it to the receiver, the FINCopy server calculates a
second PAC on the received message. This time the PAC is calculated using the SA-2
algorithm.
The original message is delivered to the recipient with the original MAC calculated by the
sender of the payment, plus the second PAC calculated by the FINCopy server.
Central
Institution
Destination
MT 103 Y-copy facility MT 303

Proprietary Authentication Proprietary Authentication
Code1 + MAC Code2 + MAC
SWIFT
Network
D0540070
Sending Receiving
In the T Copy mode, the PAC is removed from the copy message before delivery to the
receiver.
With the FINCopy service however, the requirement for authorisation by the RMA can be
bypassed, since membership of the FINCopy service includes an agreement to exchange
authenticated messages.
Bypassing authorisation is controlled by the RMA Authorisation option in the FINCopy service
profile, which is set by the service administrator. The setting of this option can be displayed in
the SWIFT Support application (RMA Authorisation field).

Appendix H - Transmission and Delivery of FINCopy Messages
H.2 Failure Conditions

Description
Conditions which cause the delivery of the message to be aborted include:
• rejection of the message by the FINCopy server
• the addressee has not logged into APC/FIN for a period of more than 14 days
• the receiver has negatively acknowledged the message more than 10 times
• the Central Institution has not sent an authorisation for more than 14 days
• with SWIFTNet PKI, failure of message authentication and authorisation (FINCopy server not
set up to bypass RMA)
If the message is aborted, then the normal FIN functionality is used to notify the sender.
15 July 2011 637

Appendix I
The FINCopy Server

Introduction
The FINCopy Server is installed on an Alliance system at the central institution destination. Its
principal task is to respond to MT 096 "settlement requests" which are forwarded to the server
from the FINCopy facility of the SWIFT network.
Authentication is done using the SWIFTNet PKI methods. Authorisations can be done by the
Relationship Management Application or FINCopy can be set up to bypass RMA authorisation.
For more information, see "FINCopy Service" on page 636.
Central
Institution
Destination
FIN Copy Server
FIN Copy facility
Sending SWIFT Receiving

Institution Network Institution
D0540071
I.1 Processing an Incoming MT 096
Overview
After receiving an MT 096, the response of the server (in negotiation with an external
accounting system) is to either authorise or reject the settlement request. The response to the
FINCopy facility is always made in the form of an MT 097.
Validation And Authentication

Upon receipt of an MT 096, the message undergoes FINCopy validation. This consists of
verifying the syntax of the MT 096 and the PAC (if proprietary authentication is required).
Failed Messages
All messages failing FINCopy validation are processed as if they have failed message
authentication. The failed message is flagged as having "no key" or '"PAC authentication error".
An event is recorded in the Event Journal and the related FIN session is aborted. No
acknowledgement is returned to the FINCopy facility.
Failed messages are routed to _MP_mod_rec_secu, the Reception Security Modification queue.

Appendix I - The FINCopy Server
Accepted Messages
Messages passing FINCopy validation are positively acknowledged, and then subjected to a
second PAC calculation, this time by the FINCopy server. If this PAC calculation fails, then the
message is routed to the Reception Security Modification queue.
The PAC result is packed into the MT 096, and the message is passed to the routing
application. After this stage, the processing applied to the message is totally dependent upon
the routing tables defined by the central institution destination staff. However, it is generally
assumed that the message is forwarded to an accounting system for authorisation.
I.2 Processing an Outgoing MT 097

Overview
After the MT 096 is passed to the accounting system for authorisation or rejection, the message
is returned to the FINCopy server as an MT 097. The message already contains the new PAC.
The message is then sent to the FINCopy facility on the network for delivery to the receiver.
FINCopy server connection with the Accounting System

The FINCopy server communicates with the accounting system using the Application Interface.
Messages can be exchanged with the accounting system using any message file format. The
accounting system will be known to Alliance as a "message partner", and the Interactive or File
Transfer connection method will be used to establish a connection.
Institution Destination
Accounting
System
CAS 2 NDF
Alliance
+ FIN Copy Server
To SWIFT D0540072
I.3 Re-authentication of Failed Messages

Overview
The re-authentication of failed messages is a manual operation which is handled by the
operator using the Message Modification application.
When Alliance Access cannot authenticate a recently received FINCopy message, it routes the
message to the Reception Security Modification queue (_MP_mod_rec_secu).
For a message received from the SWIFT network (for example, a FINCopy message), you can
use the Message Modification application to authenticate the Proprietary Authentication Code
(PAC).
15 July 2011 639

You can also use the main window of the Message Modification application to reauthenticate a
group of messages in the Reception Security Modification queue, (manual PAC re-
authentication cannot be bypassed). For more information, see "Creating Messages" in the
Daily Operations Guide. Alternatively, you can display a single message within the Message
Modification window to modify it so that it can be re-authenticated. For more information, see
"Modifying Messages" in the Daily Operations Guide.
Regardless of the message format, if the re-authentication is successful, Alliance Access then
routes the message according to the routing rules defined for the Reception Security
Modification queue. By default, authenticated messages are routed to the System Exit Point, as
specified in the routing rule of _SI_from_SWIFT.
If authentication fails for any message, then that message remains in the Reception Security
Modification queue.
I.3.1 Message Retrieval

Overview
User-to-user message retrieval requests are possible from the FINCopy server using the MT
020, and network response MT 021.
Upon reception of an MT 021, the MT 096 is extracted and subjected to the same FINCopy
validation check as a message received directly from the SWIFT network.
Note Retrieved messages result in the delivery of two messages: the MT 021 and the
extracted MT 096.
A journal entry is made for each retrieved message.

Use of the MT 020 and MT 021 is the same as for normal network operations.
I.3.2 FINCopy Server Control (VTB users only)

Overview
Senders of FINCopy messages using the Vendor Test Bed (VTB) can determine how the
FINCopy server processes received MT 096 messages by sending a suitably tagged MT 999.
The FINCopy server will acknowledge receipt of the MT 999 as ACCEPTED if the first line of
field tag 79: is formatted in one of the following ways:
79: ACCEPT VALID PAC
The MT 097 will be a payment authorisation. It will contain a PAC. No value for tags 114: and
115:
79: ACCEPT VALID PAC
SERVER-TO-RCVR:<32x>
SERVER-TO-SNDR:<32x>
The MT 097 will be a payment authorisation. It will contain a PAC. The values for tags 114: and
115: are filled by the values specified in the MT 999.
79: ACCEPT INVALID PAC
The MT 097 will be a payment authorisation. It shall contain the PAC value '01234567'. No
value for tags 114: and 115:
79: ACCEPT INVALID PAC

Appendix I - The FINCopy Server
The MT 097 will be a payment authorisation. It shall contain the PAC value '01234567'. The
value for tags 114: and 115: are filled with the string specified in the MT 999.
79: REJECT xx
The MT 097 will be a payment refusal (code is xx). It will contain a PAC. No value for tags 114:
and 115:
79: DROP
NO MT 097 will be generated. MT 096 is discarded by the accounting system.

79: RANDOM xx
MT 097 payments and refusals are generated in a random fashion by the accounting system
(with around 80% authorisations). Code xx is used for the refusal. It will contain a PAC. No
value for tags 114: and 115:
79: RANDOM xx
MT 097 payments and refusals are generated in a random fashion by the accounting system
(with around 80% authorisations). Code xx is used for the refusal. It will contain a PAC. The
value for tags 114: and 115: are filled with the string specified in the MT 999.
For services with normal authentication operating in Y-Copy mode, the information "VALID
PAC" and "INVALID PAC" are ignored as no PAC is required in the MT 097. The processing for
"REJECT", "RANDOM", and "DROP" is the same as when proprietary authentication is
required.
Special Note on MT 096 Acknowledgement:

79: SEND MT999 ON MT096 RECEPTION
For an MT 999 "ACCEPTED" acknowledgement to be returned to the sender on reception of
each MT 096, the sender must include this line as the first line in field tag 79 of the sent MT
999. If an acknowledgement is required, then the field tag values specified in the options above
will need to start on the second line of field tag 79.
For example, for authorisation on an invalid PAC:
79: SEND MT999 ON MT096 RECEPTION
ACCEPT INVALID PAC
I.3.3 System Service Messages

Overview
The following message types are used for basic system administration in the FINCopy service:
• MT 030 - Cut-off time reconciliation request
• MT 050 - Cut-off time reconciliation report
• MT 028 - Y-Copy message status request
• MT 029 - Y-Copy message status report
15 July 2011 641

I.3.4 FINCopy Service Definition Files

Overview
The purpose of the service definition file is to ensure that all subscriber CBTs have reference to
the same operational parameters for the FINCopy service. Periodically, SWIFT will electronically
distribute the updates, definitions, and parameters of the service to all FINCopy subscribers.
The service definition file must be installed and activated on sender/receiver CBTs, and on the
FINCopy Server CBT.
FINCopy server setup

To use the FINCopy service, you must:
• install the relevant FINCopy service parameter file in Alliance Access
• assign the FINCopy service to the LT(s) (own destinations) that will be used by the central
institution destination to send and receive MT 096 and MT 097 messages
• activate the relevant FINCopy service in Alliance Access.

Appendix J - Handling Double-Authenticated Messages with FINCopy
Appendix J
Handling Double-Authenticated Messages with

FINCopy
Overview
This appendix is intended for the Service Administrators at Central Institutions.
The appendix describes the impact on the back-office applications of the Service Administrators
of FINCopy services, which exchange messages through Alliance Access. In particular, the
appendix covers the methods of authentication and the signing algorithms that were introduced
as part of SWIFTNet Phase 2. These new signing algorithms require the exchange of additional
information containing special characters between the interface and the back-office application
of the Service Administrators of FINCopy services. Alliance Access does not support the
formats RJE, DOS, MERVA/2 and CAS-1, in the scope of FINCopy services.
J.1 Message Flow

Introduction
This section describes the message flow and implementation of double-authenticated messages
(in the scope of the Y-Copy mode), authenticated by means of SWIFTNet PKI signatures.
Figure 3
MT
(8)
(7) MT
(2)
MT
Institution A Institution B
(1) (9)
MT MT
(3) (6)
Service Administrator's CBT

MT MT
(4) (5)
D0900001
Back Office Application
15 July 2011 643

"Figure 3" on page 643 represents the message flow of a double-authenticated message from
the moment that the emitting interface constructs and sends it until the moment that it is
delivered at the receivers interface.
Explanation of the message flow
1. The emitting institution A issues a message, for example an MT 103, to its correspondent
institution B.
The emitting institution prepares a USER signature containing:
• the SignDN
• a Manifest element containing the reference(s) to and the digest value(s) of those parts
of the payload that require authentication
• an Object element containing a random number

For a double-authenticated message there are two parts of the payload that require
authentication:
• the FIN message requires a MAC-equivalent authentication. The USER signature

element is extended with a digest value calculated on the complete FIN message. The
reference to this digest value is "M". The random number, provided in the Object
element of the USER signature, is part of the input used for the digest value calculation
of the MAC-equivalent authentication
• based on the FINCopy service Profile, the complete message, or only a part of it
requires a PAC1-equivalent authentication. A digest value is calculated and added to the
USER signature. The reference to this digest value is 1.
Upon emitting, SWIFTNet Link signs the message and converts the USER signature into a
SYS signature.
2. The MT 103 arrives at the SWIFT Central System.

Based on the service profile (as defined by the SA), the SWIFT Central System extracts a
number or all of the fields contained in block 4 of the MT 103.
It creates an MT 096 message, with a block 4 that contains block 1, 2, 3 (if present), 4
(limited to the extracted fields) and 5 of the MT 103. The MAC- and PAC1-equivalent
authentication is provided through the SYS signature and passed with the MT 096
message.
Note The Object element, containing the random number, is removed from the SYS
signature.
3. The SWIFTNet Link of Alliance Access receives the message.

The SWIFTNet Link verifies the SYS signature and passes the message to Alliance Access
together with the verification result. If the verification of the SYS signature was successful,
then Alliance Access will verify that the PAC1-equivalent digest.
Alliance Access can define routing rules to send a message that failed authentication
directly to the back office or to require operator intervention. If operator intervention is
needed, then the operator can take one of the following actions:
• Bypass the authentication
• Route the message (to the back-office application)

• Re-authenticate the message, in case the reason for failure may have been fixed
You cannot re-authenticate system messages or MT 096 messages. You can only
progress system messages by using the Bypass Security command.
• Complete the message (without further treatment)

The message (including the authentication status) is forwarded to the back office (except in
the last case).
4. The back office receives the message and evaluates the business request. It decides to
accept or reject the request and if optional field 115 (<payment-release-
information-receiver>) is used.
5. The back office prepares an MT 097 message which, amongst other fields, contains the
accept or reject status - indicating to SWIFT if the message can be released - and transfers
it to Alliance Access.
6. Alliance Access receives the message and prepares a (new) USER signature for PAC2-
equivalent authentication. It calculates the digest value: this digest value is referenced to as
"2".
The MT 097 is sent to the SWIFT Central System. SWIFTNet Link converts the USER
signature into a SYS signature.
7. The SWIFT Central System creates:
• an MT 012 if the MT 097 contains an accept indication and if it is requested by the

FINCopy service, or
• an MT 019 if the MT 097 contains a reject indication

and sends it to institution A.
8. If the MT 097 contains an accept indication, then the SWIFT Central System releases the
original message and delivers it to institution B, together with the SYS signatures calculated
in stage 1 and in stage 6.
9. Institution B receives the message.

Its SWIFTNet Link verifies both SYS signatures and passes the message together with the
verification results to the SWIFT interface application of institution B.
If the SYS signature verification was successful then the SWIFT interface application
verifies the MAC- and PAC2-equivalent digests. Routing rules can be defined to send a
message that failed authentication directly to the back office or to require operator
intervention. If operator intervention is needed, then the operator can take one of the
following actions:
• Bypass the authentication
• Route the message (to the back-office application)
• Re-authenticate the message, in case the reason for failure may have been fixed
You cannot re-authenticate system messages or MT 096 messages. You can only
progress system messages by using the Bypass Security command.
• Complete the message

The message (including the authentication status) is forwarded to the back office (except in
the last case).
15 July 2011 645

J.2 Implementation
J.2.1 Generic Implementation
Overview
To prepare the PAC2-equivalent USER signature in Step 6 of "Figure 3" on page 643, Alliance
Access must calculate its <DigestValue>; for this calculation, it must have access to the
following data elements:
• BIC8 of the central institution destination
• BIC8 of the receiver
• block 4 of the original message (or a part of it in case of partial copy)
• the signature value on the M digest, if an M digest is present, as calculated by the emitting
institution (that is, the signature value of the Signature element containing the MAC-
equivalent digest)
• field 115 (<payment-release-information-receiver>), if used

These data elements are added by the back office when preparing the MT 097 during stage 5
on page 645.
• the back office decides whether to use the optional field 115
• the back office adds the following data elements by means of extra fields (in addition to the
fields defined by the MT 097 message standard):
– BIC of the receiver of the original message
– the original message type
– block 4 of the original message as it has been copied in the MT 096
– signature value on the M digest, if an M digest is present

The back office must have received this information from Alliance Access in Step 4 of "Figure 3"
on page 643, together with the PAC1-equivalent authentication status. The PAC1 authentication
status passed by Alliance Access to the back office in Step 4 of "Figure 3" on page 643 has one
of the following values:
• FAC: authenticated with the PAC1-equivalent signature
• FAB: authentication bypassed
• FAI: authentication incorrect

Figure 4
MT MT
MT103 MT 103
(M+P1) (M+P1, P2)
MT MT
MT 096 MT 097
(M+P1) (P2)
MT MT
MT 096 MT 097
(M+P1, BIC of receiver, (M+P1 [signature value only],
BIC of emitter, Original BIC of receiver, Block 4 of the
message type, Block 4 of original message, Field 115 (optional))
the original message)
D0900003
M+P1 = MAC - and PAC1 - equivalent Signature
P2= PAC2 - equivalent Signature
Therefore, the following requirements apply to the back office:
• The back office must have access to the signature value. This is achieved by providing the
whole SYS signature to the back office
• If the SYS signature contains an M digest, then the back office must provide the signature
value of the received SYS signature back to Alliance Access.
J.2.2 Implementation in Alliance Access

Overview
In Step 3 of "Figure 3" on page 643 (when Alliance Access forwards the MT 096 to the back-
office application), the required information is provided to the back office as described in the
following table:
MQSA format RJE, DOS, CAS-2 NIF / CAS-2 NIF / ADK

MERVA/2 and NDF Text NDF ASN.1
CAS-1 encoding encoding
formats(1)
BIC of emitter Contained in Not supported Contained in Contained in Contained in

of original block 1 of the block 1 of the block 1 of the block 1 of the
message message message message message
embedded in embedded in embedded in embedded in
MT 096 MT 096 MT 096 MT 096
BIC of Contained in Not supported Contained in Contained in Contained in

receiver of block 2 of the block 2 of the block 2 of the block 2 of the
15 July 2011 647

MQSA format RJE, DOS, CAS-2 NIF / CAS-2 NIF / ADK

MERVA/2 and NDF Text NDF ASN.1
CAS-1 encoding encoding
formats(1)
original message message message message
message embedded in embedded in embedded in embedded in
MT 096 MT 096 MT 096 MT 096
Original Contained in Not supported Contained in Contained in Contained in

message type block 2 of the block 2 of the block 2 of the block 2 of the
message message message message
embedded in embedded in embedded in embedded in
MT 096 MT 096 MT 096 MT 096
Signature SIG trailer in S- Not supported field SIGV field sigValue field
value on the M block, appe_pki_pac2
digest containing _value in the
complete SYS reception
signature appendix
PAC1- Trailer in block Not supported field PACR field pacResult field
equivalent S of MT 096 appe_pki_pac2
authentication _result in the
status reception
appendix
(1) These formats are no longer supported in the scope of FINCopy services.
In Step 6 of "Figure 3" on page 643, the required information is received from the back office
through the following fields in the MT 097 (as described in "Generic Implementation" on
page 646): 102, 124, 199, and 999. Field 999 is a field tag (SignatureValue) and is listed as
Reserved for internal use in the FIN System Messages. If the SYS signature does not contain
an M digest, then the field 999 is passed without content.
Alliance Access removes these fields when sending the message to the SWIFT Central System.
Note The back office must be able to extract the signature value on the M digest from
the SYS signature.
J.3 Examples of MT 096 and MT 097 with PKI

Signatures
MT 096 received by Alliance Access from SWIFT Central System
The following MT 096 is received by Alliance Access.
MT 096
Example
{1:F01DCRIFRTAAXXX0165005109}
{2:O0960933041018DYLRXXXXEXXX00000176830410180533S}
{3:{103:COP}
{108:SMAIBE22A1033570}}
{4:
{1:F01SMAIBE22AXXX0246001570}

{2:I103SMAIBE23XXXXN}
{3:{103:COP}}
{4:
:20:COP/103/test01
:32A:041025EUR1,
-}
{5:{MRF:041018093334041018SMAIBE22AXXX0246001570}}
{5:{CHK:73AC90A7A3F1}
{SYS:0933041018SMAIBE22AXXX0246001570}}
The MAC- and PAC1-equivalent authentication is provided by means of the following SYS
signature:
SYS signature Comments
<SwSec:Signature>
<SwSec:SignedInfo>...</SwSec:SignedInfo>
<SwSec:SignatureValue>PEMF@Proc-Type... Elements specific to SYS signature

<SwSec:KeyInfo>...</SwSec:KeyInfo> Contains the SignDN
<SwSec:Manifest>
<Sw:Reference>
MAC-equivalent
<Sw:DigestValue>...</Sw:DigestValue>
</Sw:Reference>
<Sw:Reference>
<Sw:DigestRef>1</Sw:DigestRef>
PAC1-equivalent
</Sw:Reference>
</SwSec:Manifest>
</SwSec:Signature>
This example contains two <Sw:Reference> instances:
• one for the MAC-equivalent, with <Sw:DigestRef> equal to M
• one for the PAC1-equivalent, with <Sw:DigestRef> equal to 1

Other <Sw:Reference> elements can be present (for example, for end-to-SWIFT signature):
these are left out for readability.
MT 096 Transferred from Alliance Access to back office

Alliance Access transfers the MT 096 to the back office as follows:
• MQSA format
15 July 2011 649

A new S-block trailer is added containing the complete <SwSec:Signature> element:

{S:{FAC:}
{SIG:<SwSec:Signature>...</SwSec:Signature>}}
• CAS-2 NIF or NDF Text Encoding format

The PKI signature is delivered to the back office by means of a new field named SIGV:
:SIGV:nnnnn:<SwSec:Signature>...</SwSec:Signature>
whereby nnnnn stands for the length of the signature element starting with
<SwSec:Signature> and ending with </SwSec:Signature> (both tags included).
• ADK
The information is transferred to the back office by means of designated fields:
Signature value: appe_pki_pac2_value in the reception appendix
PAC1 equivalent authentication status: appe_pki_pac2_result in the reception

appendix
MT 097 Transferred from back office to Alliance Access

The back office provides Alliance Access with the following MT 097:
Message Comments
{1:F01MASGSGSMAXXX0122000199}
{2:I097SWFTXXXXXXXXS}
{4:
{103:COP}
{109:090514091701090514SENDRBICAXXX0685697419}
{451:0}
{114:PAYMRELINFO2SENDER}
{115:PAYMRELINFO2RECEIVER}
{102:SMAIBE23AXXX} Receiver BIC
{124:103} Original Message Type
{199: Start of block 4 of original msg
:20:COP/103/test01 Original msg field
:32A:041025EUR1, Original msg field
-} End of block 4 of original msg
{999:PEMF@Proc-Type...}} New field tag - SignatureValue
For the MT 097, note that:
• field 117 is absent (MAC of the original message)
• in case of TARGET, field 102 does not occur twice

• field 999 is added, which contains the SwSec:SignatureValue of the signature element of
the original message.
Note If the MT 097 contains a reject indication, then a PAC2-equivalent USER

signature must be provided in Step 6 of "Figure 3" on page 643. As of
SWIFTNet Phase 2, the back office must therefore always provide Alliance
Access with fields 102, 124 and 199.
MT 097 Sent by Alliance Access to SWIFT Central System

Alliance Access performs the following actions on the received MT 097:
• removes from block 4 all fields starting with field 102 until the end of block 4
{1:F01MASGSGSMAXXX0122000199}
{2:I097SWFTXXXXXXXXS}
{4:
{103:COP}
{109:090514091701090514SENDRBICAXXX0685697419}
{451:0}
{114:PAYMRELINFO2SENDER}
{115:PAYMRELINFO2RECEIVER}
}
{5:{CHK:73AD80A7A3F1}}
• prepares the PAC2-equivalent USER signature (it finds all the required input in the MT 097 it
just received):
USER Signature Comments
<SwSec:Signature>
<SwSec:KeyInfo>...</SwSec:KeyInfo>
<SwSec:Manifest>
<Sw:Reference>
<Sw:DigestRef>2</Sw:DigestRef>
PAC2-equivalent
</Sw:Reference>
</SwSec:Manifest>
</SwSec:Signature>
15 July 2011 651

Appendix K
Command-line Tools
Introduction
The following diagnostic tools are used to get system information that is useful for investigating
a problem. These tools can also be used to recover from certain problems related to message
partners:
• getmesg
• messageTool
• ResetMp (on UNIX, reset_mp)
• saa_supportinfo
• saa_system integrity
• systeminfo (on UNIX only)

In addition, the following tools are also available:
• sa_split
• sa_extract
Running the tools

Note that the tools can be run in two ways:
• By entering the command from the directory where the tool is located.
• From another location. In this case, you must provide the full path, and command.
Getting help
You can display the syntax for each tool by entering one of the following commands:
• <tool name>
• <tool name> -h
where <tool name> is the name of the tool that you want to use.
K.1 getmesg
Overview
Use the getmesg tool to obtain database information about a specific message. The tool can
be used with the servers running or stopped.
Note You cannot use the getmesg tool to retrieve information about a message that
was restored from a backup of the Message Archive from Alliance Access Release
6.0.x. Instead, you must use the saa_bankquery tool to retrieve information
about the message.

Appendix K - Command-line Tools
Tool location
Windows:<Alliance installation directory>\BSS\bin\win32
AIX: <Alliance installation directory>/BSS/bin/AIX
Solaris: <Alliance installation directory>/BSS/bin/SunOS
Command syntax
Windows:
getmesg
-u "UUMID"
-s DATESUFFIX
[-o <output file>]
[>><errorfile>]
UNIX:
getmesg
-u "UUMID"
-s DATESUFFIX
[-o <output file>]
[2><errorfile>]
Parameters
Parameter Description Mandatory?
UUMID The UUMID of the searched message (can be extracted from the Message Yes
File). It must be specified between double quotes (").
-s DATESUFFIX The concatenation of the message creation date (YYMMDD) and the suffix Yes
displayed in the Message File.
-o <output file> The location of the path and the filename of a file where the output of the
command is redirected. If the option is not specified, then the command
output is displayed on the screen.
>><errorfile> Used to save the returned error in a file (Windows).
2><errorfile> Used to save the returned error in a file (UNIX).
To run the tool on Windows
1. Start the Alliance Installation application and double-click the Command Prompt icon.
2. In the Command Prompt window, run the getmesg command with the required
parameters.
For example:
getmesg -u "IALLIBEAAXXX999ABCD1234" -s 0004062345 -o c:\temp\getmesg.out
>> c:\temp\mesgerror.out
To run the tool on UNIX
1. Log on as Alliance Access System Administrator.
2. From the System Administration application select xterm from the OS Configuration
menu.
3. In the Xterm window, run the getmesg command with the required parameters.
15 July 2011 653

For example:
getmesg -u "IALLIBEAAXXX999ABCD1234" -s 0004062345 -o /temp/getmesg.out 2>/
temp/mesgerror.out
Result
If the command is run successfully, Alliance Access writes an event to the Event Journal with
the following information about the message:
• the UUMID of the message for which the getmesg tool was run (a concatenation of the
message creation date (YYMMDD) and the suffix of the message for which the getmesg tool
was run)
• the date and time at which the getmesg tool was run
• the operating system account of the operator that launched the tool
K.2 messageTool
Overview
The messageTool command is used to unreserve or to complete all messages at a particular
routing point. The tool can only be used when the Alliance Access servers are stopped.
Tool location
Command syntax
messageTool
-r <Routing point name>
-c | -u
Parameters
<Routing point name> The name of the Routing Point where the messages to process are located. Yes
-c Option to be used if the messages must be completed.
-u Option to be used if the messages must be unreserved.
2. In the Command Prompt window, run the messageTool command with the required
parameters.

menu.
3. In the xterm window, run the messageTool command with the required parameters.
Result
If the command is run successfully, Alliance Access writes an event in the Event Journal, with
the UMID and instance number of the message instance that was completed or unreserved.
K.3 reset_mp
Overview
reset_mp is used to reset and disable a message partner profile. On Windows, the tool is
called ResetMp.
The tool can be used only when the Alliance Access servers are stopped.
Tool location
Windows:<Alliance installation directory>\MXS\bin\win32
AIX: <Alliance installation directory>/MXS/bin/AIX
Solaris: <Alliance installation directory>/MXS/bin/SunOS
Command syntax
reset_mp
<Message partner name>
Parameters
<Message partner The name of the message partner to reset. Yes

name>
2. In the Command Prompt window, run the ResetMp command with the required
parameters.
menu.
3. In the xterm window, run the reset_mp command with the required parameters.
15 July 2011 655

Result
If the command is run successfully, Alliance Access writes an event to the Event Journal with
the name of the message partner profile that was reset.
K.4 systeminfo (UNIX only)

Overview
The systeminfo tool is used to display information about the following items:
• system
• hardware configuration
• log files
• core file
• network status
Tool location
Command syntax
systeminfo
[2><error file>]
Parameters
2><error file> Used to save the returned error in a file.
menu.
2. In the xterm window, run the systeminfo command with the required parameters.
Result
The resulting file systeminfo.tar is located in $TMPDIR (if defined). The default path is /
usr/tmp.
K.5 saa_supportinfo
Purpose
The saa_supportinfo tool is used to collect a variety of system-related information over a
specified period and store it in a Zip file. The Alliance System Administrator sends the Zip file to
Support, for the investigation of problems.

Alliance Access configuration data, event journal, trace files, and logs are part of the information
that is collected. However, secure information is not collected, for example, passwords or keys.
Important Some events related to FIN messages contain the full message payload. If you do
not want the FIN message payload to be collected with this tool, then use the
Journalise Msg Text security parameter.
Impact of database operations

The Alliance System Administrator can run this tool at any time, regardless of whether the
Alliance Access database is running or not. If the database is not running, then the tool tries to
start the database.
• If the database starts successfully, then the collected information is saved in an output file.
• If the database fails to start, then the tool only collects information that does not require
database access, and saves it in an output file.
Tool location
Command syntax
saa_supportinfo
[-output <output_dir>]
[-from <From_datetime>]
[-to <To_datetime>]
[-hc]
[-help]
Parameters
-output <output_dir> The directory in which the output file is stored.

If you do not use the -output option, then the output file is stored in the
support folder, under the installation root folder of the Alliance Access
software (that is, \Alliance\Access\support).
-from <From_datetime> Specifies the time period, in the format YYYYMMDD[THHMM], during which
-to <To_datetime>put information is collect. This information includes ( the event journal, trace
files, and log directory.
If you do not use this option, then the tool collects logging information from
the previous 24 hours.
If -from and -to are present, then the logging information for the specified
day period is retrieved.
If the date is specified but not the time, then the default time is 00:00:00 for
<From_datetime>, and 23:59:59 for <To_datetime>.
If only -from <from_datetime> is present, then the logging information for
the specified date is retrieved for a period from the time specified, or, by
default, 00:00:00 to 23:59:59.
If only -to <To_datetime> is present, then the logging information for the
specified date is retrieved for a period from 00:00:00 to the time specified,
or, by default, 23:59:59.
-hc Checks the integrity of the operating system and resource information.
15 July 2011 657

-help Provides help.
1. Log on as Alliance System Administrator to the host machine where Alliance Access is
installed.
3. In the Command Prompt window, run the saa_supportinfo command with the required
parameters.
1. Log on as Alliance System Administrator to the host machine where Alliance Access is
installed.
2. From the System Administration application window, select xterm from the OS
Configuration menu.
3. In the xterm window, run the saa_supportinfo command with the required parameters.
Result
The syntax of the output file name is saa_supportinfo.<YYYYMMDDTHHMMSS>.zip
Where:
• YYYYMMDD and THHMMSS are the creation date and time of the zip file
The zip file contains two directories with the collected information:
• config, for the configuration information
• log, for the logging information.
Configuration information that is collected

The configuration information includes the following:
• application server information (such as certificate, configuration file)
• database configuration information (provided by the saa_dbinfo and saa_dbconfig

commands)
• system information (provided by the checkhost tool and the Report utility)
• software integrity information (provided by the saa_system integrity command)
• Alliance Access licence information (provided by the Report utility)
• Alliance Access configuration information (for example, installation.properties)
• dump of the following Alliance Access entities:
– routing information: routing points, routing rules, routing keywords
– configuration information: calendar definitions, configuration parameters, units
– message partner configuration and session details

– SWIFTNet emission and reception profiles details
– operator profiles and operator definitions
– logical terminal definitions
– control tables for the message and event daily table sets
Logging information that is collected

The logging information includes the following:
• the installation.log file
• Installation checkhost report files
• Alliance Access product events log for the specified time frame
• database log and alert files
• log files of the embedded application server (in case of Server-Embedded products).
The time-related options (-to and -from) limit, when applicable to the Alliance Access
product, the extracted information for:
– the event journal
– the database alert and trace files
– content of the log directory (only files with a last modification date that falls in the [from-
to] time frame).
K.6 saa_system integrity

Purpose
You can use the saa_system integrity command to verify the integrity of the Alliance
Access software files and Alliance Developers Toolkit components.
Note The security parameter, Software Check At Startup, controls whether the Integrity
Verification Tool is run each time that Alliance Access is started.
Tool location
Windows:<Alliance installation directory>\bin
AIX: <Alliance installation directory>/bin
Solaris: <Alliance installation directory>/bin
Command syntax
saa_system integrity
15 July 2011 659

Parameters
integrity [short] Verifies the integrity (absence of unauthorised updates) of the Alliance
[<adk_component_names Access software files.
> This command launches the Integrity Verification Tool. The tool generates
a full integrity report that is compared to the last full integrity report which
was produced during installation or upgrade.
Specify [short] to run a less-intense check.
Specify <adk_component_names>, to check only specific components of the
Alliance Developers Toolkit. If you omit this parameter, then all components
of the Alliance Developers Toolkit are checked.
2. In the Command Prompt window, run the saa_system integrity command with the
required parameters.
menu.
2. In the xterm window, run the saa_system integrity command.
K.7 saa_query
Purpose
You can run a query to extract the content of events or messages (live or archived) from the
database. The query provides the contents of events or messages that were created within a
specific time period.
The results are provided in an output file, which uses the same XML format as the Alliance
Access Web services for queries on messages.
Note You do not need the Web services licence package to use this command.
Prerequisites
Before launching the command, check the following conditions:
• The Alliance Access server must be running in either operational or housekeeping mode.
• If the Alliance Administrator runs the command and the -user or -application
parameters are excluded, then the Software Owner Profile security parameter must specify
a valid operator profile.
Tool location

Operator session
Your Alliance Access licensing agreement allows only a certain number of operators to use the
system concurrently. Running this command starts an operator session with Alliance Access,
and this session is included in the count of concurrent users of the system.
Command syntax
saa_query
[-user|-application <username>]
[-password <password>] | [-passwordfile <password_file>]
[-overwrite]
[-port <port_number>]
-outputfile <file_pathname>
-message|-event
[-start <yyyymmddThhmmss> -end <yyyymmddThhmmss>]
Parameters
-user <username> The name of the Alliance Access operator of type Human executing the
command.
If the -user or -application argument is not specified, then the software
owner must launch the command. In this case, the Software Owner
Profile security parameter must be defined.
-application The name of the Alliance Access operator of type Application executing the
<username> command.
If the -user or -application argument is not specified, then the software
owner must launch the command. In this case, the Software Owner
Profile security parameter must be defined.
-password <password> The password of the Alliance Access operator.

You can use one of the options to specify the password:
• -user|-application <username> -password <password>:

Enter the user name and password in the command line. If you omit the
password, then you receive a prompt to enter it.
• -user|-application <username> -passwordfile <passwordfile>:

Specify the password file name, which contains the password. The
password included in the password file is not encrypted. The access
rights that are associated with the password file control the access to
the password.
-passwordfile The name of the password file that contains the password.
<password_file>
-overwrite Specify this parameter to overwrite the values in an existing output file. If
you omit this parameter, then no changes are made to an existing output
file.
-port <port_number> The port number of the local host in which the Alliance Access is listening.
Default port number: 48200.
-outputfile The name of the output file in which details of the messages or the events Yes
<file_pathname> are stored.
-message|-event Specify one of the following parameters: Yes
• -message: export the content of messages
15 July 2011 661


• -event: export the content of events
-start Specify this parameter to indicate a date and time from which to start and
<yyyymmddThhmmss> - end the extraction of messages or events from the database. The time and
end <yyyymmddThhmmss> date are local to the server.
If you omit this parameter, then the tool is run on the current day from
00:00 to 23.59.
2. Run the Installation application and open a Command Prompt window.
3. In the Command Prompt window, run the saa_query command with the required
parameters.
The contents of all messages or events that have a creation time or date within the time period
are exported from the database to an output file.
2. From the System Administration application, select Xterm from the OS Configuration
menu.
3. In the xterm window, run the saa_query command with the required parameters.
The contents of all messages or events that have a creation time or date within the time period
are exported from the database to an output file.
Log file
When you run the command, Alliance Access creates a log file,
saa_query_<Timestamp>.output, with the details about the time and the date that the tool
was used. It also provides the name of the output file.
Related information
For more information about the XML format that is used in the output file, see the Web Services
Developer Guide.
K.8 sa_split
Overview
The sa_split tool is used to split any large file into chunks. This can be used for outputs of
the saa_supportinfo tool, or for any other files that Support may ask you to send on an
exceptional basis.
Tool location

Command syntax
sa_split
[-size <size>]
<filename> | -combine <filepath_name>
Parameters
<filename> The name of the file to be split.
-size Used to specify the size (in MB) of each chunk.

If you do not use this option, then each chunk has a default size of 2 MB.
The resulting files are named <filename>.xx, where xx is a sequence
number (01..99).
-combine Combines chunks of a previously split file into a single file.

<filepath_name> If the file specified already exists, then the tool returns an error.
2. In the Command Prompt window, run the sa_split command with the required
parameters.
menu.
2. In the xterm window, run the sa_split command with the required parameters.
15 July 2011 663

Legal Notices
Copyright
SWIFT © 2011. All rights reserved.
You may copy this publication within your organisation. Any such copy must include these legal notices.
Confidentiality
This publication may contain SWIFT or third-party confidential information. Do not disclose this publication
outside your organisation without the prior written consent of SWIFT.
Disclaimer
SWIFT supplies this publication for information purposes only. The information in this publication may
change from time to time. You must always refer to the latest available version on www.swift.com.
Translations
The English version of SWIFT documentation is the only official version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT,
the SWIFT logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or
company names in this publication are trade names, trademarks, or registered trademarks of their respective
owners.

7 0 Saa Sys Man Guide

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

7 0 Saa Sys Man Guide

Diunggah oleh

Hak Cipta:

Format Tersedia

Connectivity

Alliance Access 7.0.20

System Management Guide

Part A – Introduction ........................................................................................................................................11

2 Using Applications ....................................................................................................................................... 24

Part B – Housekeeping Tasks ..................................................................................................................37

4 Installing Message Syntax Tables ......................................................................................................... 46

5 Creating and Configuring Your Logical Terminals ........................................................................ 49

6 Managing the MX Message Standards ................................................................................................ 54

2 System Management Guide

7 Installing Value-Added Services ............................................................................................................ 57

8 Assigning Routing Keywords ................................................................................................................. 65

9 Modifying Active Routing Rules ............................................................................................................. 67

Part C – Configuring Alliance Access ................................................................................................69

11 Managing Alliance Access Security ..................................................................................................... 77

12 SWIFTNet Security ..................................................................................................................................... 121

13 Defining Printers (UNIX only) ................................................................................................................ 123

14 Installing Application Services Profiles ............................................................................................ 126

15 Defining SWIFTNet Profiles .................................................................................................................... 128

16 Configuring SWIFTNet Connections .................................................................................................. 148

17 Configuring System Parameters .......................................................................................................... 158

18 Configuring Event and Alarm Distribution ...................................................................................... 171

19 Configuring the Calendar and Scheduling Processes ............................................................... 185

20 Updating the Correspondent Information File ............................................................................... 215

4 System Management Guide

20.8 Activating and Deactivating Correspondents .................................................................................... 235

21 Managing Message Partner Profiles .................................................................................................. 243

22 Managing Exit Point Profiles ................................................................................................................. 302

23 Configuring Queues ................................................................................................................................... 307

24 Message Routing ........................................................................................................................................ 314

24.6 Routing - Criteria Definition Window .................................................................................................. 328

25 Configuring Message Delivery (Delivery Subsets) ...................................................................... 344

26 Import/Export of Message Templates ................................................................................................ 357

27 Increasing Message Throughput ......................................................................................................... 362

Part D – Appendices .......................................................................................................................................367

6 System Management Guide

D.2 RJE .......................................................................................................................................................... 414

K.8 sa_split .................................................................................................................................................... 662

8 System Management Guide

10 System Management Guide

12 System Management Guide

1 Understanding the Basics

1.1 The Alliance Access Options

• Installation groups applications that control the installation of Alliance Access.

• Help opens the online help system.

1.2 Signing on to Alliance Access

Signing on for the first time

To sign on to Alliance Access:

2. Select Programs from the Windows Start menu.

3. Select Alliance Access.

5. Enter your Operator name and Password.

14 System Management Guide

Enter your existing password in the Old Password field.

1.3 The Access Control Window

• The Message Creation application is used to create SWIFT FIN messages.

• The Relationship Management application is used to authorise FIN messages.

• The SWIFTNet Support application is used to configure the SWIFTNet connections.

16 System Management Guide

1.4 The File Menu

1.4.1 Setting the Refresh Rate

To set the refresh rate:

3. Click Modify to confirm your changes.

1.4.2 Setting Up the Printer

To set up the printer: