Service Description: Alliance Access 7.1

Connectivity
Alliance Access 7.1
Service Description
This service description provides information about the features and functions of Alliance Access and describes the roles
and responsibilities of SWIFT and the customer in relation to Alliance Access. This document is for Alliance Access
users, SWIFT partners, and service bureaux.
27 March 2015
Alliance Access 7.1
Table of Contents
.Preface .............................................................................................................................................................................4
1 Overview of Alliance Access ..................................................................................................................... 6
2 System Requirements ................................................................................................................................... 8

2.1 Hardware .................................................................................................................................................... 8
2.2 Operating System ..................................................................................................................................... 8
2.3 SWIFTNet Software .................................................................................................................................. 9
2.4 Database Model ........................................................................................................................................ 9
3 SWIFTNet Messaging Services ............................................................................................................... 10
4 Message Formats .......................................................................................................................................... 11
5 Message Validation ...................................................................................................................................... 13
6 Message Management ................................................................................................................................ 15

6.1 Message Preparation ............................................................................................................................. 15
6.2 Message Processing .............................................................................................................................. 17
6.3 Message Authentication and Authorisation ......................................................................................... 18
6.4 Message Search ..................................................................................................................................... 19
6.5 Message Routing .................................................................................................................................... 19
6.6 Operational Reporting ............................................................................................................................ 20
7 Application Integration ............................................................................................................................... 22

7.1 Alliance Access Integration Platform ................................................................................................... 22
7.2 Web Services ........................................................................................................................................... 26
7.3 Alliance Access Developers Kit ............................................................................................................ 27
8 Integration with Customer Business Applications ........................................................................ 28

8.1 File Transfer Host Adapter ..................................................................................................................... 29
8.2 IBM WebSphere MQ ............................................................................................................................... 29
8.3 Simple Object Access Protocol (SOAP) .............................................................................................. 30
8.4 Direct FileAct ............................................................................................................................................ 30
8.5 CREST ...................................................................................................................................................... 30
9 Desktop Access ............................................................................................................................................. 31
10 Operator Profile Management ................................................................................................................. 34
11 Correspondent Management ................................................................................................................... 36
12 Relationship Management Application ............................................................................................... 37
13 System Management ................................................................................................................................... 38

13.1 System Monitoring .................................................................................................................................. 38
13.2 System Management Functions ........................................................................................................... 39
2 Service Description
Table of Contents
13.3 Backup and Restore ............................................................................................................................... 41
14 Resilience ......................................................................................................................................................... 44
15 Standalone Alliance Access .................................................................................................................... 46
16 Third-Party Software .................................................................................................................................... 48
17 Ordering ............................................................................................................................................................ 49
18 Support .............................................................................................................................................................. 50
19 Roles and Responsibilities ....................................................................................................................... 51

19.1 Alliance Access Licence ......................................................................................................................... 51
19.2 SWIFT's Roles and Responsibilities .................................................................................................... 54
19.3 Customer's Roles and Responsibilities ............................................................................................... 55
20 Contractual Framework .............................................................................................................................. 57

.Legal Notices ...............................................................................................................................................................58
27 March 2015 3
Alliance Access 7.1
Preface
Purpose of this document
This service description provides information about the features and functions of Alliance
Access and describes the roles and responsibilities of SWIFT and the customer in relation to
Alliance Access.
It also provides information about the features and functions of the Standalone Access. To
activate and use the Standalone Access functionality, customers must license Alliance Access
7.1 for Standalone Access only.
Customers can find the latest available version of this document at www.swift.com > Support >
Documentation.
Note This service description, together with the SWIFT General Terms and Conditions
and other relevant SWIFT contractual documentation, is an integral part of the
contractual arrangements between SWIFT and its customers for the provision and
the use of Alliance Access.
Audience
This document is for the following audience:
Customers that require information about the features and the functions of Alliance Access.
Customers that require information about the roles and the responsibilities that relate to
Alliance Access.
SWIFT partners and service bureaux.

The use of Alliance Access by SWIFT partners and service bureaux may be subject to
specific restrictions. For example, a registered provider may only use Alliance Access for
integration and testing purposes.
SWIFT-defined terms
This document contains terms that have a specific meaning in the context of SWIFT
documentation (for example, customer, user, or SWIFT services and products).
These terms, which are either defined in this document or in the SWIFT Glossary, are identified
as shown in this example:
SWIFT provides secure, standardised messaging services and interface software to its
customers.
Significant changes
The following tables list all significant changes to the content of the Alliance Access Service
Description since the January 2014 edition. For more information, see the Alliance Access
Release Letter. These tables do not include editorial or structural changes that SWIFT makes to
improve the usability and comprehension of the document.
Updated information Location
Update to the IPLA section "Alliance Access Integration Platform" on page

22
Update to the third-party software section "Third-Party Software" on page 48
Preface
Deleted information Location
References to MQSA and CAS Throughout the document
Related documentation
Customers can also refer to the following documents in relation to the information in this service
description.
the Alliance Web Platform SE documentation set
the Alliance Access documentation set
Alliance Access Release Letter
Alliance Gateway Service Description
Alliance Remote Gateway Service Description
Connectivity Packs
FIN Service Description
the relevant Standards MT Message Reference Guides
the relevant Standards MX Message Definition Reports
the relevant Support Service Description
SWIFT General Terms and Conditions
SWIFTNet Link Service Description
SWIFTNet Service Description
SWIFTNet and Alliance Release Policy
SWIFTNet Resilience Guide
OS Levels and Patches Baseline
27 March 2015 5
Alliance Access 7.1
1 Overview of Alliance Access

About Alliance Access
Alliance Access is SWIFT's prime messaging interface designed to connect customers'
business applications to SWIFT messaging services. Alliance Access receives, processes,
routes, and forwards messages and files across the SWIFT network and across a variety of
back-office applications.
Alliance Access provides various host adapters to connect to a range of back-office applications
that SWIFT, third parties, or customers have developed. Alliance Access also includes
capabilities for customised integration with third parties. SWIFT has designed Alliance Access to
communicate with all the SWIFTNet messaging services and to handle the volumes of most
demanding SWIFT customers. Alliance Access is a qualified FIN, InterAct, FileAct and RMA
interface.
For more information about the functions supported for each SWIFTNet messaging service, see
the Alliance Access conformance statements available on www.swift.com > Products &
Services > Partners > Interface qualification programme.
Overview of Alliance Access
Overview of Alliance Access
File Transfer
MQ Workstation Browser
IPLA SOAP
Web Services Direct FileAct
ADK Web Platform
Application Back-Office Desktop

Integration
Integration Application Access
Messaging Alliance Access

Software
Profile and
Correspondent Management
Monitoring and System

Management
Message Management
and Routing
RMA
Communications Alliance Gateway

Software
Alliance Remote Gateway
Network Alliance Gateway

Connection
FIN
InterAct SWIFTNet D0540196
FileAct
Software components
The Alliance Access software comprises a number of different applications. Depending on the
licence options that the customer selects, the customer can perform the following tasks:
connect to SWIFTNet
configure and manage connections to SWIFTNet messaging services
connect to the customer's internal network and systems
manage RMA authorisations
integrate Alliance Access with back-office systems and applications
configure and control Alliance Access
prepare, send, and receive messages
send and receive files
27 March 2015 7
Alliance Access 7.1
2 System Requirements
2.1 Hardware
Basic configuration
Customers can implement Alliance Access in a client-server configuration. A minimal Alliance
Access configuration is an IBM AIX, Oracle Solaris, Red Hat Enterprise Linux, or Microsoft
Windows system that has a graphical user interface running on a Microsoft Windows system.
SWIFT can help potential Alliance Access customers to assess individual hardware
requirements.
The Alliance Access/Entry Release Letters, the System Configuration Recommendations and
Guidelines and the Connectivity Packs documents define, based on the anticipated throughput,
the memory and the Central Processing Unit (CPU) that systems require to run Alliance Access.
SWIFT recommends that customers implement a hardware backup system to protect data and
software.
Memory and disk requirements

The minimum memory and disk requirements for Alliance Access may increase in relation to the
following factors:
the message and file traffic
the amount of archived messages and journal entries
the number of operator sessions
the number of configured message partners
the amount of data kept for Operational Reporting
Connection between the end user and Alliance Access

End users connect to Alliance Access through GUI packages that are running from Alliance
Web Platform SE and accessible to the browser on the end-user's desktop system.
The connection between the browser and Web Platform SE must have a minimal bandwidth of
128 kbps with a maximum latency of 100ms.
Note Only Internet Explorer and Firefox web browsers are supported.
2.2 Operating System

Operating systems for use with Alliance Access
Alliance Access is qualified to operate with IBM AIX, Oracle Solaris, Red Hat Enterprise Linux,
and Microsoft Windows Server.
Customers can find details about the operating system (OS) levels and the OS patches on
which the connectivity products have been qualified at www.swift.com > Support >
Documentation.
System Requirements
2.3 SWIFTNet Software

SWIFTNet software requirements
Alliance Access requires Alliance Gateway or Alliance Remote Gateway to ensure secure
communication with and connection to SWIFTNet and the SWIFTNet messaging services. For
Alliance Gateway connectivity, Alliance Access embeds the Remote API software, which does
not need to be installed separately. The Remote API Host Adapter option is required on Alliance
Gateway when Alliance Access is not running on the same host as Alliance Gateway. For more
details, see the Alliance Gateway Service Description. For Alliance Remote Gateway
connectivity, Alliance Access embeds the Remote API Client Gateway software, which does not
need to be installed separately. For more details, see the Alliance Remote Gateway Service
Description.
For graphical services, Alliance Web Platform or Alliance Workstation is required.
For the most up-to-date information about SWIFTNet software (for example, new software
patches) and the supported Standards Releases, see www.swift.com > Support > Download
centre.
Note Alliance Workstation is not available for Alliance Access on Red Hat Enterprise
Linux.
Alliance Workstation will be retired by end of March 2017.
2.4 Database Model

Overview
Alliance Access requires an Oracle database to store its configuration and operational data.
Alliance Access supports two configuration options:
an embedded Oracle database
a hosted database
In both configurations, customers are not allowed to directly access and manipulate the content
of the Alliance Access database.
Embedded Oracle database

In this model, the management of the Oracle database is done by Alliance Access and totally
transparent to the end user.
Hosted database
The use of the hosted database model is subject to the activation of a licence option.
In this configuration, Alliance Access installs its database on an Oracle instance provided by the
customer.
27 March 2015 9
Alliance Access 7.1
3 SWIFTNet Messaging Services

Support of all SWIFTNet messaging services
Alliance Access supports the exchange of messages with the following SWIFTNet messaging
services:
FIN
Customers can use Alliance Access to exchange MT messages over the FIN service.
InterAct
Customers can use Alliance Access to exchange XML-based messages over an InterAct
service.
Note Alliance Access cannot act as a real-time InterAct server.
FileAct
Customers can use Alliance Access to exchange files over a FileAct service.
Note Alliance Access cannot act as a file download server.
RMA
Customers can use Alliance Access to exchange authorisations with correspondents over the
RMA service.
Message Formats
4 Message Formats
Introduction
File Transfer
IPLA SOAP
ADK Web Platform
Application Back-office Desktop

Integration
Messaging Alliance
Software Access MT XML File
Communications Alliance
Software Gateway Alliance Remote Gateway
Alliance Gateway
Network
Connection
SWIFTNet
D0540203
Note Alliance Workstation is not available on Linux.
Alliance Access supports different message formats:
MTs carried over FIN
XML-based messages (such as, MXs, FpML, AnyXML) carried over InterAct
FileAct messages (also referred to as files) carried over FileAct
Messages in proprietary format supported within the Integration Platform (IPLA)
MT messages
Alliance Access processes, stores, and routes MT messages. SWIFT develops and deploys the
MT messages.
MT messages standards are loaded in Alliance Access through the Message Syntax table. A
Message Syntax Table contains the information that relates to a specific MT Standards
Release.
27 March 2015 11
Alliance Access 7.1
Deployment Packages downloaded from MyStandards provide MT messages restricted to the

Business Usage Guidelines of the publisher of these packages. It is the responsibility of the
publisher to test these packages before making them available to the community.
MX messages
Alliance Access processes, stores, and routes MXs, XML-based messages. SWIFT develops
and deploys the MX messages using the ISO 20022 methodology.
MX messages are used in the scope of SWIFT Solutions, such as Exceptions and
Investigations, Cash Reporting, and Funds. These solutions and the MX messages are loaded
in Alliance Access with Deployment Packages.
Deployment Packages downloaded from MyStandards can provide MX messages restricted to
the Business Usage Guidelines of the publisher of these packages. It is the responsibility of the
publisher to test these packages before making them available to the community.
FpML messages
Alliance Access supports the exchange of FpML messages used in the scope of the Derivatives
solution.
AnyXML messages
Alliance Access supports the exchange of any well-formed XML business messages to and
from SWIFTNet. To achieve such transfers, Alliance Access supports an exchange mechanism
AnyXML. AnyXML allows a back-office application to exchange XML message with Alliance
Access when no Deployment Packages are available in Alliance Access. Such messages
cannot be manually edited when residing in Alliance Access.
FileAct messages
Alliance Access supports the exchange of files over FileAct.
To generate a FileAct exchange, the following two elements are required:
the payload file
the associated FileAct emission settings
Proprietary messages
Alliance Access supports exchange of messages in proprietary format in the context of
processing developed for the Integration Platform. Such messages cannot be manually edited
when residing in Alliance Access. For more information see 7.1 "Alliance Access Integration
Platform".
Message Validation
5 Message Validation
MT messages
Alliance Access uses the following criteria to validate MT messages that the customer sends:
the mandatory fields must be present
the correct syntax is checked against the Message Syntax Table

Alliance Access performs a syntax validation of MT messages.
MX messages
Alliance Access uses the following criteria to validate MX messages that the customer sends or
receives:
the messages must be well-formed XML messages
if a Deployment Package is loaded, then keywords are extracted (no syntax check is done,
except for manual entry)
The Deployment Packages define how Alliance Access processes the MX messages. A
Deployment Package contains the information that relates to a specific MX Standards Release.
Alliance Access does not perform a syntax validation of MX messages based on the content of
the Deployment Package. Alliance Access only validates that the XML is well formed and refers
to a service with an associated Deployment Package loaded in Alliance Access.
The Deployment Package is also used by the Message Management GUI of Alliance Web
Platform SE to generate the expanded view of an MX message. On Alliance Web Platform SE,
the Deployment Package is required for the manual creation of MX messages. When creating
messages manually and with the Deployment Package installed, the syntax validation feature is
provided in the message entry GUI.
FpML messages
Alliance Access does not perform validation of FpML messages.
The FpML Deployment Package can be used to view the message and perform keyword
extraction when applicable. Alliance Access does not support the manual creation of FpML
messages.
AnyXML messages
Alliance Access does not perform validation of AnyXML messages. Alliance Access only
validates that the MX message is a well-formed XML document.
When a back-office application provides an MX message flagged as AnyXML, Alliance Access
does not attempt to locate an associated Deployment Package for the service referenced in the
MX message. Consequently, Alliance Access only validates that the MX message is a well-
formed XML document, and does not perform any routing keyword extraction. MX messages
received from SWIFTNet, with no corresponding Deployment Package in Alliance Access, are
also marked as AnyXML when stored in Alliance Access and transferred to back-office
applications.
FileAct messages
Alliance Access does not check the file content and does not perform validation of FileAct
messages. Consequently, Alliance Access does not validate FileAct header information related
to the file content.
27 March 2015 13
Alliance Access 7.1
Proprietary messages
Processing developed for the Integration Platform can support validation of source or target
messages in the context of message transformation.
Business Usage Guidelines
Alliance Access allows the import of Business Usage Guidelines defined through Deployment
Packages downloaded from MyStandards. MT and MX messages created manually in Alliance
Access using such a Business Usage Guideline will also be validated against the following
restriction types of MyStandards:
prevent a field from being used
make an optional field mandatory
reduce the multiplicity of a field (enforce less iterations of the same field)
enforce a fixed value for a field
change the datatype for a field

This validation is only available during the manual processing of messages created manually
with the Message Management GUI. Messages received from SWIFT or from a back-office
system cannot be validated against a Deployment Packages downloaded from MyStandards
that defines Business Usage Guidelines.
Validation process
Alliance Access can validate messages for structure and content when messages arrive at
certain points in the application.
Alliance Access can validate a message at the following stages:
at the point at which the user manually creates a message or after text modification (including
validating the Business Usage Guidelines).
when Alliance Access receives a message from a back-office application, and before Alliance
Access sends a message to the message destination (depending on the validation level set
of the message partner handling the back-office messages).
when Alliance Access receives a message from a messaging service (for example, from
FIN).
Message Management
6 Message Management
Overview
Alliance Access offers comprehensive message management functionality, such as manual
message creation, verification, authorisation, repair (modification) and consultation.
When applicable, customers can also consult, verify, authorise and modify messages created
by back-office applications. Back-office applications can send a message as read-only, meaning
that it cannot be modified in Alliance Access.
Messages received from SWIFT are consulted only (repair only deals with authentication
issues).
To create messages, customers can also use any third-party solution that conforms to the
SWIFT message standards and that can connect to Alliance Access over its host adapters or
through connectivity with a project running in the Integration Platform.
Type of Message Management

Messages
Manual Consult Verify(1) Authorise Repair Report
Creation
MT Workstation Workstation Workstation Workstation Workstation Web

and and and and and Platform
SE
Web Platform Web Web Web Web Platform
SE Platform SE Platform SE Platform SE SE
MX Web Platform Workstation Web Web Web Platform Web

SE and Platform SE Platform SE SE Platform
SE
Web
Platform SE
Files NA Workstation NA Web NA Web

(FileAct and Platform SE Platform
messages) SE
Web
Platform SE
(1) Fields to be verified are defined through the Deployment Package, customers can also define additional fields.
Related information
For more information about the Message Management GUI package of Alliance Web Platform
SE, see "Desktop Access" on page 31.
6.1 Message Preparation

Manual creation
To create messages manually in Alliance Access, customers have different options:
Customers can use the Message Management package of Alliance Web Platform SE or the
Message Creation application of Alliance Workstation to create MT messages.
Customers must use the Message Management package of Alliance Web Platform SE to
create MX messages.
Customers can use the Message Management package of Alliance Web Platform SE to
create FileAct files and initiate real-time file download requests.
27 March 2015 15
Alliance Access 7.1
Note With the FileAct messaging service, customers can initiate real-time or store-
and-forward file emission and real-time file download.
To create MT or MX messages manually using the Message Management package of Alliance

Web Platform SE, customers must upload a Deployment Package for the appropriate service in
Alliance Access.
To create an MT or MX messages in line with a Business Usage Guideline defined in
MyStandards, customers must upload the associated Deployment Package in Alliance Access.
Message templates
Customers can use message templates to create new MT and MX messages according to
requirements and business use. On-screen guidance for message creation is also available. MT
message templates are defined centrally in Alliance Access and are available to both Alliance
Workstation and Web Platform users. MX message templates are available only to Alliance
Web Platform SE users.
Verify messages
Customers can verify all MT and MX messages that contain business-critical information (for
example, Currency, Amount, or Value Date). Customers can either use the Message
Management package of Alliance Web Platform SE or the Message Approval application in
Alliance Workstation to verify manually created messages or messages that the customer has
received through a message partner. Customers must verify messages individually.
To ensure accuracy, a second operator usually verifies each SWIFT financial message before
transmission. This operator displays a message from the verification queue. The application
shows the important verifiable fields (usually Currency, Amount, and Value Date) without any
data. The second operator must re-enter this data. The application automatically compares the
new data with the original data. If there are any discrepancies, then the disputed field changes
to the error colour, and the application records an event in the Event Journal. The operator can
then try to re-verify that particular field.
Note Customers can bypass verification and authorisation processing for non-business-
critical messages.
Alliance Access does not support the verification of FileAct messages.

The fields that need to be verified are defined in the Deployment Package of the relevant
solution. The release letter of these Deployment Packages contains the inventory of the fields
that are to be verified. Operators that have the permission to load and activate Deployment
Packages can configure additional fields as fields that must be verified.
Authorise messages
Customers can use Alliance Access to authorise manually created messages, or messages that
the customer has received through a message partner.
To authorise messages in Alliance Access, customers have different options:
For the authorisation of MT messages, customers can use either the Message Management
package of Alliance Web Platform SE or the Message Approval application in Alliance
Workstation.
For the authorisation of MX or FileAct messages, customers must use the Message
Management package on Alliance Web Platform SE.
Customers can either authorise individual messages or batches of messages.
Message Management
Customers are responsible for building appropriate processes and usage practices around
verification and authorisation to ensure that all messages are sent as intended and that no
unintended messages (like duplicate messages without Possible Duplicate indicator) are sent to
the correspondent.
Repair messages
To repair messages manually in Alliance Access, customers have different options:
Customers can use the Message Management package of Alliance Web Platform SE or
Alliance Workstation to repair MT messages.
Customers must use the Message Management package of Alliance Web Platform SE to
repair MX messages.
Alliance Access automatically routes messages that require modification after initial message
creation, or that have failed verification or authorisation, to one of the message modification
queues for repair. Alliance Access also routes messages that the SWIFT network negatively
acknowledges (NAKs), to a message modification queue.
Alliance Access does not support the repair of FileAct messages.
Note Customers can also use a standalone Alliance Access system for manual message
creation and repair. For licence details, see section "Alliance Access Licence" on
page 51.
6.2 Message Processing

Introduction
All functions mentioned in this section are applicable to MT, MX, and FileAct messages.
Send and receive messages

Alliance Access can send messages to a correspondent or receive messages from a
correspondent. Alliance Access can also receive messages (see "Message partners" on page
29) that the customer's back-office application has created. Alliance Access sends these
messages to a correspondent. Alliance Access can then receive the response from the
correspondent and deliver it to the customer's back-office application.
Generate copies of messages

During message processing, Alliance Access can generate copies of a message for distribution
to different departments inside a customer's organisation. Customers can use copies of
messages only for information and notification purposes.
Re-activate messages
Customers can re-activate a message and direct it to a message queue. Customers can also re-
activate a completed message for further processing on the same or another exit point. Alliance
Access can reset the message status to live and can route the message to an exit point. For
more information about the life cycle of a message, see the Alliance Access Getting Started
Guide.
27 March 2015 17
Alliance Access 7.1
Message priority
Alliance Access provides an internal message priority feature, which allows users to assign/
change the priority of messages at or after message creation. Alliance Access will then ensure
that these messages are treated according to their current priority during their whole lifecycle in
Alliance Access.
Message information
Customers can retrieve information about a message from the Message File. The Message File
stores information that Alliance Access has received from the messaging service. Examples of
this information are the acknowledgements or negative acknowledgements that the customer
receives from SWIFT.
Duplicate detection
Alliance Access supports full duplicate detection. The full message payload (FIN text block,
InterAct payload, FileAct digest) is taken into account to detect a message as duplicate.
The detection occurs against all non-archived, live or completed messages present in the
Alliance Access database.
Enhanced real-time handling

Alliance Access supports real-time messaging for both InterAct and FileAct. For environments
where back-office systems do not have the features to perform appropriate re-emission of
messages to assure a reliable communication, Alliance Access provides a series of features to
increase reliability of transmission. When emission over a real-time service to a specific
correspondent fails Alliance Access will retry until a specific expiry date/time is reached.
Customers can fine tune the expiry behaviour at different levels to meet the needs of different
message flows. When necessary, customers can put a specific correspondent on hold and
release message flow when appropriate.
6.3 Message Authentication and Authorisation

Authentication
The authentication methods that Alliance Access uses to authenticate the different message
types are as follows:
SWIFTNet Public Key Infrastructure to authenticate MT messages
the requestor and responder Distinguished Names (DNs) and SWIFTNet Public Key
Infrastructure to authenticate MX messages and FileAct messages
Mandatory local authentication

If the Alliance Access runs on a system that is different from the system on which Alliance
Gateway runs or when Alliance Access uses Alliance Remote Gateway, then SWIFT mandates
the use of the local authentication method. This method ensures the identity of the sender and
the receiver and the integrity of any SWIFTNet traffic that Alliance Access and the Alliance
Gateway exchange.
Optional local authentication

Alliance Access also provides the optional local authentication between Alliance Access and
back-office systems to ensure identity of the sender and the receiver and the integrity of any
SWIFTNet traffic that Alliance Access and the back-office system exchange.
Message Management
Authorisation
Alliance Access uses the RMA data and the application service profiles (ASPs) to verify whether
messages and files are authorised to be exchanged with correspondents.
6.4 Message Search

Search for messages
Alliance Access stores every message (MT, MX, FileAct or proprietary messages) that it
processes, as well as information about messages in its database. Alliance Access also
automatically reconciles delivery notifications for all message formats. Customers can search
and query the database, and retrieve sent or received messages. Customers can use Alliance
Access to search archived messages. There is no message status limitation or time constraint
that restricts the customer's ability to investigate messages. By investigating a message,
customers can avoid the requirement to send message retrieval requests to SWIFT. Customers
can use the stored information in Alliance Access to form a precise view of message traffic and
message processing.
Note Customers can use the Message Management package of Alliance Web Platform
SE to consult MX, FileAct, and proprietary messages.
The content of file payload for FileAct messages is never displayed or printed.
Business or technical criteria

Customers can use Alliance Access to search for messages according to business criteria or
more technical criteria. Examples of business criteria include Currency, Amount, and Value
Date. Examples of technical criteria include Session Number and Sequence Number.
6.5 Message Routing

Routing functions
Alliance Access provides customers with extensive message-routing functions, supporting MT,
MX, and FileAct messages.
Alliance Access can route several instances of the same message independently. For example,
Alliance Access can send one instance to the back office and a copy instance to the printer.
Routing points
Alliance Access routes messages through a series of routing points. Each routing point links to
a message processing function that fetches, processes, and routes the queued messages at
this routing point. Alliance Access does not impose a fixed flow or any rigid routing requirements
at these routing points. However, there is a minimal set of internal rules to protect the integrity
and behaviour of Alliance Access.
Message queues
Alliance Access stores messages internally in queues. Each message queue has a set of
routing rules that determines the flow of messages from one queue to the next queue for
processing.
During message preparation, Alliance Access holds messages in queues according to the
message status. At all stages of processing, Alliance Access can generate message status
changes, return message changes to the sender, and copy messages.
27 March 2015 19
Alliance Access 7.1
User-defined queues
The Alliance Access administrator can define additional queues, the user-defined queues, used
solely for the purpose of routing messages based on their content. Alliance Access routing
allows to route messages from one user-defined queue to another user-defined queue.
Routing rules
Alliance Access uses routing rules to route messages between queues. Alliance Access assigns
routing rules to routing points, and can also associate these rules with routing schemas.
Customers can use Alliance Access to define message routing rules. Customers can specify
that Alliance Access routes messages to a queue and sends these messages to a
correspondent. Alliance Access accesses the Correspondent Information File to find the
network that the customer prefers. Customers can define routing rules to ensure that Alliance
Access directs messages in specific message formats to the appropriate network.
The Message Syntax Table and the deployment packages are used in Alliance Access to
perform the routing keyword extraction. A list of keywords are defined by default, such as
Reference, Currency, Amount and Value Date. Customers can also define additional routing
keywords for extraction of specific fields (full or partial) of a given message. The values of these
fields are used as message search criteria and for routing purposes.
Routing schemas
An Alliance Access routing schema groups a set of routing rules. When Alliance Access has
assigned the routing rules to a schema, the schema must be approved and then activated. To
process messages that arrive at a routing point, Alliance Access uses only those routing rules
that it has assigned to the active schema. Customers can use the pre-defined routing schema
or duplicate the schema and modify it to match specific processing requirements.
6.6 Operational Reporting

Introduction
Alliance Access Operational Reporting is a licence option that allows a customer to generate
message-related reports addressing various operational needs.
Alliance Access Operational Reporting is fully integrated into the system, providing the
environment to execute reports either interactively, as an option of the Message Management
package of Alliance Web Platform SE, or from a command-line tool, as well as providing an
initial set of ready-to-use operational reports.
Note Operational Reporting is available only with the Message Management package.
Licensing
When ordering Alliance Access Operational Reporting, the customer must specify the total
number of production BICs that can be used for reporting. When licensing the option on the
system, the customer must choose the production BICs to report against, up to the maximum
allowed BICs by the licence.
Message Management
Ready-to-use reports
Alliance Access Operational Reporting provides a set of ready-to-use reports, addressing
various operational reporting needs linked to message activity within the system. The reports
are grouped by categories based on their operational purpose. The environment is designed to
allow SWIFT to provide additional reports in the future.
Alliance Access Operational Reporting is available as a function of the Message Management
package of Web Platform, allowing the customer to browse through the various reports installed
on the system to select the report to execute. When executing a report, the system allows the
customer to provide a value for the various parameters supported by each report, as well as to
specify the report delivery options and the report output format. Each report has its own set of
parameters. Customers can generate the reports in PDF, CSV, browser, Microsoft Word, or
Microsoft Excel format.
The customer can either execute the report interactively, and wait for the output to be generated
and displayed on screen, or execute the report in background mode and display the report
output later (see "Report history").
The customer can also save the provided report parameters for future re-use (see "My reports").
Report history
For each report execution, Alliance Access logs the execution details and the associated report
output. The customer can access this execution log in the Message Management package of
Alliance Web Platform SE, looking at the details of each report execution and possibly
displaying again the report output without having to re-execute the report.
This list is dynamic per user of Alliance Access, showing only the report executions that can be
accessed by a given user.
My reports
The customer can save the parameter values used to generate a given report, under a user-
specified name.
The customer can execute a report directly using saved parameter values. This function
facilitates the periodic execution of reports. The customer can specify relative values instead of
absolute values for date-based parameters, to support periodic execution.
Alliance Access Operational Reporting also provides a command-line tool to set up automatic
generation of reports. When executed from the command-line tool, the customer must specify
the saved set of parameter values to use to generate the report output.
27 March 2015 21
Alliance Access 7.1
7 Application Integration
Introduction
Alliance Access offers different integration capabilities:
Alliance Access Integration Platform (IPLA)

The Alliance Access Integration Platform is a powerful standards-based integration platform
built into Alliance Access. IPLA allows development and hosting of integration solutions.
When such a solution is deployed within IPLA, Alliance Access can accept messages in
proprietary formats and transform them into SWIFT message formats. Similarly, such
processing can transform messages that arrive in SWIFT format to the appropriate
proprietary format. These integration capabilities can also be used to allow third-party
applications to integrate into the main message flow of Alliance Access.
Web Services
Web Services is an industry standard technology and provide services allowing an external
application to query specific content in the Alliance Access database.
Alliance Access Developers Toolkit (ADK)

ADK is an integration method specific to Alliance Access and is primarily designed to allow
third-party applications to integrate into Alliance Access main message flow mechanism. It
also provides additional services on Alliance Access messages.
7.1 Alliance Access Integration Platform

Introduction
The Alliance Access Integration Platform (IPLA) is a licence option that provides the application
integration capability to both connect new flows to SWIFT and to enhance existing business
flows. As a platform built into Alliance Access, IPLA provides a framework to develop and host
integration solutions. Integration solutions deployed in IPLA can exchange messages in a
proprietary format with customer business applications and support transformations between
proprietary message formats and SWIFT message formats. Business applications can use IPLA
to exchange data with Alliance Access without requiring extensive changes in their application
logic or format for messages. IPLA is a framework in which custom logic is developed to
address the specific integration requirements of a customer. SWIFT Consulting Services can
design, develop, and test this custom logic for the customer's solution in the scope of a separate
integration project.
This section describes Alliance Access Integration Platform (IPLA) features and functions, and
certain tasks related to their use.
Wherever this document specifies that a task is the customer's responsibility, that task may be
performed, at the customer's choice, by one of the following entities or means:
the customer
SWIFT Consulting Services

While knowledgeable and qualified third-party service providers may be able to assist with
certain tasks, it is always advisable to confer with a SWIFT representative regarding the
relevant service.
Application Integration
7.1.1 Connecting to Business Applications

Connectors for business application connectivity
IPLA provides the following connectors to exchange content with business applications:
File connector
Web services (acting as a server), deployed in IPLA based on either the SOAP or RESTful
protocol
IBM WebSphere MQ connector, which relies on the WebSphere MQ Java API (MQI)
Apache Camel JMS connector, which is used in combination with the WebSphere MQ JMS
API
JDBC connector, with which the customer can optionally use stored procedures. The
customer is responsible for providing and maintaining the database. SWIFT supports JDBC
connectivity and stored procedures with an Oracle database only.
Message standards
IPLA supports the following message standards:
MT message structure that can be found in SWIFT libraries, which are located in and used by
the mapping tool of IPLA.
MX messages (deployment packages available from SWIFT or schemas available from the
ISO 20022 web site)
Other XML message definitions can be used through the AnyXML format. The schemas must
be obtained from the respective defining organisations.
Data, file, formats and, transformations

Business applications can exchange information with IPLA in almost any format. Some
examples of formats are comma-separated value (CSV), fixed-length records, Microsoft Excel
files, or RJE files. The custom logic defined as part of an integration project transforms the
content from proprietary format to a SWIFT standard format, and vice versa.
Content of a file to be sent from a business application to Alliance Access can be transformed to
contain MT or MX messages.
Likewise, flows handling files received from Alliance Access can transform the content to
messages in a proprietary format, MX-formatted messages, or MT-formatted messages.
File content for pass-through flows in either direction is transparent to IPLA and to Alliance
Access. A pass-through flow can include messages in any format relevant for the sender and
the receiver.
7.1.2 Message Validation and Transformation

Message validation requires custom logic
IPLA does not provide any message validation out of the box. A customer must work with
SWIFT Consulting Services to determine specific validation needs in the scope of an integration
project. Based on the agreed needs, custom logic for validation can be developed for use in a
customer's environment.
27 March 2015 23
Alliance Access 7.1
Optional proprietary message validation

Custom logic can be implemented to validate content of proprietary messages before they are
transformed to MT or MX messages.
Optional MX schema validation

Custom logic can be implemented to support MX schema validation. SWIFT Consulting
Services can develop any custom logic needed to perform cross-field validations or other
validations.
Optional FIN semantic validation

Custom logic can be implemented to support FIN semantic validation. SWIFT Consulting
Services can develop any custom logic needed to perform cross-field validations or other
validations for ISO 7775/15022 message formats.
Support for message format transformation

IPLA does not include any pre-built transformation services for business messages. SWIFT
Consulting Services can implement any necessary transformation logic, using the features
provided with IPLA.
On the flow from a business application to Alliance Access, custom logic implemented in IPLA
can transform proprietary messages to SWIFT standard message formats. Custom logic must
also be developed to transform the related ACK/NAK or notifications.
On the flow from Alliance Access to a business application, custom logic implemented in IPLA
can transform standard MT, MX, or FpML messages to the customer's proprietary format.
Transformation tools
IPLA includes a mapping tool to assist SWIFT Consulting Services in the development of
custom logic for transforming proprietary messages to SWIFT standard messages and vice
versa. IPLA includes utilities that SWIFT Consulting Services can use for transformation to and
from the structures needed for data exchanged with Alliance Access.
7.1.3 Business Flows Definition

Identify generic patterns
SWIFT Consulting Services and customer staff must jointly discuss the processing needs for an
integration project. Further analysis must then identify the relevant patterns to use when
developing custom logic for business flows.
IPLA supports generic integration patterns. Under specific conditions, some of the following
generic patterns could be used:
Single to single
A single message of one format is transformed to a single message of a different format.
A file containing multiple messages is processed without transforming any messages in the
file (that is, a pass-through flow).
Group to group
A group of messages, typically a file, is split into individual messages, each of which is
transformed to a different format. The transformed messages are subsequently grouped
again and sent for further processing.
Singles to group
Individual messages are grouped according to a set of criteria. The resulting group of
messages is sent for further processing.
Group to singles
A group of messages is split into individual messages, each of which is transformed to a
different format. The resulting individual messages are sent for further processing.
Combining patterns into flows

The generic patterns can be seen as building blocks. When these patterns are used with
specific connectors and flow direction is considered, most basic integration activity can be
modelled.
SWIFT Consulting Services performs analysis using generic patterns and enterprise integration
patterns in their activities to develop custom logic for integration projects. The mapping for
proprietary message exchange requires more specific analysis and development.
Enhancement of existing message flows

Integration solutions that provide validation, transformation and data enrichment features can
support existing Alliance Access message flows as well as new message flows.
7.1.4 Reuse of Alliance Access Features

As an Alliance Access component, IPLA reuses a variety of Alliance Access features such as
the Message File, the Event Journal, the Message Management GUI, Monitoring GUI,
Configuration GUI and configuration parameters.
IPLA includes a default queue for error management, but any additional queues needed for
processing a flow using IPLA can be provisioned within Alliance Access as part of deploying an
integration solution. This enables seamless integration with the message routing as provided by
Alliance Access.
IPLA provides a way to store package-related configuration data which is stored as Alliance
Access parameters. This data is provisioned during the installation of an IPLA package. The
configuration data is changeable through the Alliance Access configuration GUI. IPLA packages
can read this configuration data. IPLA packages cannot store business data.
7.1.5 Specific Integration Considerations for IPLA

Development data for IPLA may include several artefacts such as transformation logic for the
mappings, programming code as well as specific configuration data. As these artefacts may
need to be updated over time, it is essential that such data be available when needed. The
customer is responsible for the management of the source artefacts (that is, transformation logic
and programming code) as IPLA does not provide a tool for such purposes. The customer is
also responsible for the content of specific configuration data and for making it available within
Alliance Access, using the tool that IPLA provides for such purposes.
Compiled integration code is installed in IPLA using of a command-line tool. Compiled code
installed in IPLA is part of the backup/restore mechanism. Customers must ensure the
integration logic for use with IPLA remains available in case it needs to be installed on another
Alliance Access instance or in case it needs to be updated.
27 March 2015 25
Alliance Access 7.1
IPLA uses of the Alliance Access database to store messages, operational data, and
configuration data. The content of this database is accessible only through the usage of the API
provided with IPLA.
The Alliance Access database includes a specific unstructured file that customers' applications
can use for storing or accessing run-time data. The database connection provided with IPLA
allows direct access to this data. The customer must not use this database connection for direct
access to any other table of Alliance Access. Customers are solely responsible for any
application code that uses this file. Customers are responsible for managing the content of this
file and for cleaning up data that is no longer required. Content of this file is present in the
database recovery backup, but not included in the backup/restore for configuration data. This
data file cannot be used for business data.
7.2 Web Services

Overview
Alliance Access provides a generic Web Services interface, that allows business applications,
third-party applications, or both to invoke specific services from Alliance Access using standard
web protocols.
Web Services facilitate real-time retrieval and querying of the Alliance Access database.
The following Web Services are available:
RMA search and query
messages and events search and query
W3C certificate services

The Web Services interface is available as a licence option.
RMA-based services
The following RMA Web Services queries are available:
get a list of RMA authorisations based on a set of search criteria
get the full data of a specific RMA authorisation, including references to the exchanged
queries and answers
get a list of queries and answers based on a set of search criteria
get the full data of a specific query and answer
get the approval on whether or not you are authorised to exchange a message or file with a
correspondent
Message and event-based services

To support queries on operational data (messages and events), Alliance Access provides a set
of documented Web Services, offering the capability to search and query messages and events
present in the Alliance Access database.
The following Web Services are available:
get a list of the messages based on a set of search criteria
get the full details of a message
get a list with full details of the events based on a set of search criteria
W3C certificates services
compute a signature based on a digest
validate a signature based on a digest
7.3 Alliance Access Developers Kit

Overview
The Alliance Access Developers Kit is a collection of software and documentation that
constitutes the open host adapter to Alliance Access. The Alliance Access Developers Kit
enables a customer or a third party to build its own applications for Alliance Access. The
Alliance Access Developers Kit must be contracted for separately under the terms and
conditions of the Alliance Access Developers Kit Licence Agreement. The Alliance Access
Developers Kit supports SWIFT and other message formats.
Customers can also use the Alliance Access Developers Kit to develop applications that
integrate Alliance Access with back-office applications.
Note Since Alliance Access for Linux does not support Alliance Workstation, Alliance
Access Developers Kit applications with an Alliance Workstation-based GUI are not
available for customers using the Linux platform for their Alliance Access.
27 March 2015 27
Alliance Access 7.1
8 Integration with Customer Business

Applications
Overview of the connection methods
File Transfer
IPLA SOAP
ADK Web Platform

Integration

Software
Profile and

Management
Message Management
and Routing
RMA

Software

Connection
FIN
InterAct SWIFTNet
D0540198
FileAct
Note Alliance Workstation is not available for Alliance Access servers on Linux.
Integration features
Alliance Access uses its application interface to link to other applications, back-office systems,
printers, and customer's internal networks.
Customers can integrate proprietary, legacy, or third-party banking applications with Alliance
Access to facilitate automatic message creation, processing, transfer, routing, and delivery.
Customers can configure Alliance Access to perform these tasks regardless of the originating or
destination system, or regardless of the message format.
Integration with Customer Business Applications
Host adapters
Alliance Access's integrated host adapters enable customers to transfer messages and files
between the Alliance Access system and a business application.
Alliance Access provides different types of host adapters, supporting different connection
methods, either in batch mode or interactive mode. In interactive mode, the host adapter
performs real-time message exchange without manual intervention.
The customer selects a host adapter type based on the business requirements to integrate
business applications with Alliance Access.
Message partners
The Alliance Access application interface host adapter manages message exchange with
external applications through entities called message partners.
A message partner provides Alliance Access with the following types of information about the
message exchange:
the connection method
the connection point (for example, a directory for file transfer, a queue for MQ Host Adapter)
the supported data format
the direction for sessions (to or from Alliance Access)
8.1 File Transfer Host Adapter

Introduction
Customers can use the File Transfer host adapter to exchange messages and files between
Alliance Access and a business application. By default, the File Transfer host adapter supports
the exchange of files through a manual intervention. With an additional licence option, the File
Transfer host adapter supports the automatic transfer of files.
Manual file transfer

In manual mode, customers can trigger the exchange of messages or files between a business
application and Alliance Access by manually selecting the file containing these messages.
Automatic file transfer

In automatic mode, customers can configure the File Transfer host adapter to automatically
detect files containing FIN, InterAct and FileAct messages for emission and to automatically
generate a file containing received FIN, InterAct and FileAct messages or network
acknowledgement. Customers can exchange messages between a business application and
Alliance Access without manual intervention. The automatic mode is a licence option.
8.2 IBM WebSphere MQ

MQ Host Adapter (MQHA)
Customers can exchange individual messages in real-time between the business application
and Alliance Access using IBM WebSphere MQ Host Adapter (MQHA).
The interactive message host adapter is suitable for time-critical applications.
27 March 2015 29
Alliance Access 7.1
IBM WebSphere MQ is an IBM product, which customers must purchase separately.

The MQ Host Adapter is based on message partners and is fully integrated within Alliance
Access. Customers do not require the Alliance Access Developers Kit or the licence for
Integration Platform to use this host adapter.
8.3 Simple Object Access Protocol (SOAP)

Embedded Host Adapter
Alliance Access 7.1 offers an optional embedded SOAP Host Adapter. SOAP is an interactive
adapter, similarly to MQ, but implements a point-to-point connection without the need for a
specific infrastructure, where MQ is queue based.
The SOAP Host Adapter is based on Web Services and implements a protocol to ensure a
reliable and recoverable exchange of messages over an HTTPS link. The SOAP Host Adapter
supports the exchange of MT, MX, and FileAct messages. Customers do not require the
Alliance Access Developers Kit or the licence for Integration Platform to use this SOAP adapter.
8.4 Direct FileAct

Overview
This adapter provides a simple and straightforward exchange mechanism for back office to
generate a FileAct transaction, as in this case, the back office only needs to generate the file
payload.
The FileAct settings required to generate the transaction along with the file payload, are
configured in the Direct FileAct adapter. Only a limited set of static FileAct settings are
supported with Direct FileAct.
Customers must configure a Direct FileAct message partner for each correspondent they need
to communicate with, as each message partner holds the FileAct settings to be used for that
correspondent. The Direct FileAct adapter does not support the MT and MX messages
exchange. Customers do not require the Alliance Access Developers Kit or the licence for
Integration Platform to use Direct FileAct.
8.5 CREST
Overview
Alliance Access can also be used to handle CREST traffic, given the appropriate licensing.
For more details, see the CREST over SWIFTNet Service Description.
Desktop Access
9 Desktop Access
Alliance Web Platform Server-Embedded (SE) and Alliance Workstation
Alliance Access supports two types of graphical user interface (GUI):
Alliance Web Platform SE

Packages running in Alliance Web Platform SE are thin-client GUI applications, only requiring
the availability of Internet Explorer or Firefox on each desktop using Alliance Access. Using
GUI packages does not require the installation of additional SWIFT software on the desktop.
Important In this document, references to the GUI packages running on Alliance Web
Platform SE are often referred to as Alliance Web Platform SE.
Alliance Workstation
Alliance Workstation is a fat-client GUI application, requiring the installation of SWIFT
software on each desktop using Alliance Access. Alliance Workstation is in maintenance
mode and is no longer enhanced with additional functionality. Alliance Workstation is not
available as a desktop GUI for Alliance Access running on Linux.
Important Alliance Workstation will be retired by end March 2017.
27 March 2015 31
Alliance Access 7.1
File Transfer
IPLA SOAP
ADK Web Platform

Integration

Software
Profile and

Management
Message Management
and Routing
RMA

Software

Connection
FIN
InterAct SWIFTNet
D0540197
FileAct
Note Alliance Workstation is not available on Linux.
Functionality
Customers can use Alliance Web Platform SE and Alliance Workstation concurrently with the
same Alliance Access server, facilitating the migration of users from the Workstation to the Web
Platform environment.
All users defined on Alliance Access can use either Alliance Web Platform SE or Alliance
Workstation. The permissions assigned to a user of Alliance Access define the set of functions
that this user can perform through Alliance Web Platform SE or Alliance Workstation.
Alliance Web Platform SE installation

Alliance Web Platform SE requires an application server to host the Alliance Access GUIs and
support central deployment of these GUIs.
Alliance Web Platform SE is part of the Alliance Access contract. Customers must download
Alliance Web Pltaform SE as a separate package from www.swift.com.
Desktop Access
Alliance Web Platform SE GUI packages

The graphical user interface services are provided as various software packages that the
administrator must install using the administrative services of Alliance Web Platform SE.
The following packages are provided for Alliance Access:
Alliance Message Management

supporting the management of MT, MX, FileAct and proprietary messages
Alliance Relationship Management

supporting the management of RMA authorisations
Alliance Access/Entry Configuration

supporting the configuration and administration of Alliance Access
Alliance Access/Entry Monitoring

supporting the monitoring of Alliance Access
Evolution
As of release 7.0, Alliance Workstation is in maintenance mode. Some of the 7.0 features that
require GUI support are only accessible from the GUI packages of Alliance Web Platform SE.
27 March 2015 33
Alliance Access 7.1
10 Operator Profile Management

User roles
To use Alliance Access, users must have a profile that defines the user's role and entitlements
to access the available functionality. SWIFT refers to end users of Alliance Access as operators.
SWIFT delivers Alliance Access with pre-defined profiles. The customer's left security officer
(LSO) and right security officer (RSO) assign the profiles to Alliance Access users. These
security officers can modify the profiles or create new ones according to customer requirements.
Operator authentication
There are three possible authentication methods for operators:
local authentication
one-time password
Lightweight Directory Access Protocol (LDAP) authentication

The administrator must configure the connection to an existing LDAP server and can optionally
configure a back-up LDAP server, defined in a group of LDAP servers.
One-time passwords
One-time passwords require two additional components:
a secure, PIN-protected hardware token that generates one-time passwords
an authentication server that authenticates the one-time passwords

The administrator must configure the connection to an existing authentication server and can
optionally configure back-up authentication server, defined in a group of authentication servers.
The customer can use any authentication server that supports the RADIUS user authentication
protocol.
Note Customers must acquire the necessary secure hardware tokens and the
authentication server.
Alliance Access implementation for one-time passwords includes the following functions for all
authentication servers that support the RADIUS protocol:
Alliance Access forwards the user name and the one-time password to the authentication
server for validation.
Alliance Access locks operator accounts after a pre-defined number of invalid one-time
password attempts.
SWIFT provides no support for the RADIUS challenge-response authentication feature.
Lightweight Directory Access Protocol (LDAP) authentication

With LDAP authentication, the operator authentication is provided by an external LDAP server,
provided by the customer.
The administrator must configure the connection to the existing LDAP server, and can optionally
configure a backup LDAP server, or group of LDAP servers.
Alliance Access can communicate with any existing LDAP server provided by the customer,that
is compliant with the LDAP v3 protocol.
Operator Profile Management
For an LDAP-based authentication, the administrator associates the local definition of the
operator with an LDAP identifier.
To log in successfully, the operator must provide an Alliance Access operator name, and the
password of the associated LDAP identifier.
Alliance Access operator naming rules have been adapted to provide a local operator name that
can correspond to an LDAP account name (for example, john.smith@foo.com).
Types of operators
There are two types of operators: human operators and application-based operators.
The application-based operators can only be used by a Web Service application. That is, they
cannot log in from Alliance Web Platform SE or Alliance Workstation.
The application-based operator accounts have specific password management rules,
guaranteeing that an application based on this type of operator can always authenticate against
Alliance Access. That is, the password does not lock or does not expire.
The password management rules are as follows:
The application-based operator has an auto-generated password of 18 characters.
The account does not lock in case of multiple failed logins.
Data segregation
Alliance Access enables left security officers (LSO) and right security officers (RSO) to assign
profiles to operators. Operators can use only the Business Identifier Codes (BICs) that the
specified operator profiles allow. Alliance Access uses these operator profiles to segregate the
access to message data. The operator profiles govern access for individual Alliance Access
users to the entities that control message delivery. The use of operator profiles enables a
customer to ensure that the users can only access their own message data.
For more information about data segregation, see the Alliance Access System Management
Guide and the Alliance Access Security Guide.
Central definitions of profiles

Customers can either use Alliance Web Platform SE or Alliance Workstation graphical user
interface to interact with Alliance Access, or they can use the Web Service application that
authenticates against Alliance Access.
The Alliance Access security model, based on profile definitions, is defined and used by Alliance
Web Platform SE and Alliance Workstation.
The security model is based on the Alliance Workstation model (which refers to Application,
Function and Permissions). Although the concept of Application does not exist for Alliance Web
Platform SE, the default actions associated to Application are taken into account by Alliance
Web Platform SE.
27 March 2015 35
Alliance Access 7.1
11 Correspondent Management
Reference data available in the Correspondent Information File
Alliance Access stores information about correspondents from institutions in the Correspondent
Information File. This information includes country, network, currency , and preferred network
interface records.
Customers can define shorter names, known as aliases, for correspondents. These aliases
speed up the processing during message creation. Customers can store alias information in the
Correspondent Information File.
Alliance Access uses information from the Correspondent Information File for message routing,
to automate message processing and during message creation.
Update of the Correspondent Information File

To update the correspondent information file, customers can either import information from the
Business Identifier Code (BIC) Directory for Alliance Access customers (the Alliance Bank File)
or make changes manually.
Each month, SWIFT makes the Alliance Bank File available for download by Alliance Access
customers on www.swift.com.
Customers may only use the Alliance Bank File for integration with Alliance Access. The
Alliance Bank File is not available as a stand-alone consultation product or for integration with
other software. For consultation or integration with other software, customers must order the
BIC Directory, Bank Directory Plus, or IBAN Plus Directory on swift.com > Products & services >
Reference Data.
Usage of reference data in integration with business applications

To consult reference data stored in the Correspondent Information File through APIs and Web
Services, customers must order Reference Data products that contain that information on
swift.com > Order products and services > Reference Data Directories (SWIFTRef).
In case the Alliance Bank File and manual updates are the only source of Reference Data,
usage of APIs and Web Services is not allowed to consult the Correspondent Information File.
Relationship Management Application
12 Relationship Management Application

Overview
Alliance Access enables customers to use the Relationship Management Application. The
Relationship Management Application is available through the Alliance Web Platform SE and
the Alliance Workstation. Customers can use the Relationship Management Application to
create, modify, delete, revoke, accept, and reject authorisations.
Alliance Access is capable of managing RMA authorisations for the FIN services and for the
FileAct and InterAct services that mandate RMA.
Customers can import or export authorisations either manually or according to a schedule, or
configure the export of authorisations on change. The generic Web Services layer allows the
customer's business applications, third-party applications, or both to access specific data from
Alliance Access by using standard web protocols. This setup provides an industry standard
alternative to the existing file export mechanism. See "RMA-based services" on page 26 for the
list of available Web Services queries.
RMA Plus
A licence option called Relationship Management Application Plus extends the basic
Relationship Management Application functionality so that it has the capability to create
authorisations that have additional granularity. Customers can use RMA Plus to establish an
authorisation for a specified correspondent that also defines the type of messages for that
correspondent. RMA Plus can also create granular authorisations for multiple selected BICs that
customers have licensed as own destinations.
27 March 2015 37
Alliance Access 7.1
13 System Management
13.1 System Monitoring

Monitored events and entities
Customers can monitor activities that relate to Alliance Access. Customers can also customise
the view of monitored events and entities, and filter and create reports about specific items of
interest.
Customers can monitor activities interactively on screen (using Alliance Web Platform SE or
Alliance Workstation) or from an external application (using command-line tools).
Monitored items Activity
File Transfers Monitor the transfer of files over SWIFTNet
Logical terminals Monitor the status of the live and the Test and Training logical
terminals, and the number of messages that the logical terminals
send and receive
Message partners Monitor the status of sessions with message partners, which
includes the number of exchanged messages
Queues Monitor the system's queues and show how many messages these
queues currently hold
Events Monitor the events that occur on the system
System resources Monitor the available disk space for the database, the current
server mode, the progress of archiving and backups
Processes Monitor the status of the Alliance Access processes that are in
progress
SWIFTNet profiles Monitor the status of the emission and reception profiles
Operator sessions Monitor the currently active operator sessions
IPLA Component Monitor the status of IPLA Component (an integration solution
developed with the compiled integration code), and the number of
Inflight Exchanges (messages)
IPLA Component Route Monitor the status of IPLA Component Routes (an integration flow
developed with the compiled integration code), the number of
Inflight Exchanges (messages), the number of Completed
messages, the number of Failed messages, and the Last
Processing Time
Event Journal
The Alliance Access Event Journal application logs all user actions, events, and alarms that
occur in the system. These actions are the result of either user actions or system operations.
The Event Journal provides an audit trail of all Alliance Access events. Customers can query
and search the Event Journal for audit information or specific events.
Customers can schedule automatic event archival and can archive events to any peripheral
device.
System Management
Alarms
Customers can set many events to operate as alarms. This facility can reduce the workload for
users that must monitor certain business functions or the connectivity status.
Examples of events that can trigger an alarm are as follows:
an abort of the customer's SWIFTNet connection
a message queue that exceeds the default threshold

Customers can configure specific Alliance Access events as alarms and forward the alarms to
an operator or to a third-party monitoring application.
Distribution of alarms to SNMP servers

Customers can configure Alliance Access to distribute alarms to operators and internal
destinations. Customers can also configure Alliance Access to use Simple Network
Management Protocol (SNMP). SNMP is a standard protocol for remote monitoring and
management of devices on a network. Alliance Access can use SNMP to distribute alarms to
servers so that an external application can receive and monitor the alarms.
Monitoring dashboard
Alliance Web Platform SE offers a monitoring dashboard that provides at-a-glance a colour
coded view of the status of one or multiple Alliance Access systems.
Monitoring through a command line tool

Customers can choose to monitor the system through a command-line tool. The tool allows
monitoring of the same entities that are available in the graphical user interface. The tool output
on request the monitoring status of specified entities into an XML file. The monitoring
information contained in this XML file can be integrated into an external monitoring or
supervision system.
13.2 System Management Functions

Operational mode and housekeeping mode
Alliance Access can run in the following modes:
Operational
The operational mode is the normal, multi-user mode for Alliance Access operations. This
mode provides access to all Alliance Access functionality and is the default operating mode.
Housekeeping
The housekeeping mode is a maintenance mode in which only one user can log on to
Alliance Access at any one time. In this mode, Alliance Access freezes the message queues
and does not permit message transmission or receipt.
Customers can perform certain maintenance tasks in housekeeping mode. For more
information about these tasks, see the Alliance Access System Management Guide.
Calendar
Customers can configure multiple Alliance Access calendars. Customers can configure these
calendars to recognise weekends, national holidays, and peak days and to automate certain
operational functions. For more information about how to configure a calendar, see the Alliance
Access System Management Guide.
27 March 2015 39
Alliance Access 7.1
Message archival
Customers can use either manual mode or automated mode to archive completed messages.
SWIFT recommends that customers archive messages regularly.
For more information about how to archive messages, see the Alliance Access System
Management Guide.
Schedule
Examples of Alliance Access functions that customers can schedule and automate are as
follows:
server stop and restart functions
FIN log in, log out, and select
installation of a Bank Update File
message and event archiving
import and export of Relationship Management Application authorisations
database backup
archive backup
archive removal
activation and de-activation of SWIFTNet emission profiles and reception profiles

For more information about how to schedule and automate an activity, see the Alliance Access
System Management Guide.
Management through a command-line tool

Alliance Access provides command-line based tools, supporting most of the system
management commands available on Alliance Web Platform SE or Alliance Workstation.
These command-line tools provide an alternative to the interactive use of the system
management commands, allowing these system management tasks to be scripted.
For more information about the tasks supported by the command-line tools, see the relevant
Alliance Access Administration Guide for AIX, Linux, Solaris, or Windows.
Configuration management
Alliance Access provides two command-line tools to export and import the configuration of
Alliance Access.
The export tool only operates in operational mode and supports mostly all the configuration
entities of Alliance Access. The tool does not support the export of operational data like
messages, events, and calendar entries.
The export tool

The export tool enables an administrator to specify which configuration entities must be
exported, and to specify search criteria in order to precisely control which occurrences to
export for each selected entity. The export tool generates an XML file that can be further
System Management
modified by an administrator, allowing the configuration to be modified outside the Alliance

Access system.
The import tool

The import tool takes as input the exported configuration file, and updates the configuration
of Alliance Access based on the information available in this file. The import tool can add new
entities, or update existing ones. The import tool does not support the deletion of entities. The
import tool supports both operational and housekeeping mode, as some entities can only be
added or modified in housekeeping mode.
To modify an entity, the same rules applicable to an interactive user also apply to the import
tool. For example, an entity cannot be in Enabled state when modified by the import tool.
After import, the same approval rules also apply as for the graphical interface (for example,
approval of modified operators, approval of modified routing schema). These approvals must be
done interactively.
For more information about the export - import command-line tools and a description of the
supported entities, see the relevant Alliance Access Administration Guide forAIX, Linux, Solaris,
or Windows.
13.3 Backup and Restore

Introduction
Alliance Access provides different backup and restore facilities, covering a variety of functions:
backup and restore of Alliance Access configuration data
archival, backup and restore of Alliance Access operational data (messages and events)
on-line database backup, available only with the Database Recovery licence option
13.3.1 Configuration Data Backup and Restore

Description
Alliance Access performs a backup of the configuration data only. The operational data
(messages and events) are excluded.
The configuration data backup is available as two separate tools, one to back up the data and
another tool to restore these backups into an Alliance Access system.
The configuration data backup is used to restore the configuration on a system, typically to
prepare a new system or to restore the configuration of a corrupted system.
It is not suitable for protection against operational data loss.
Customers can execute a configuration data backup on-line. That is, without having to stop
Alliance Access.
Activation
Customers can activate the configuration data backup using either of the following options:
automatically through the Calendar function of Alliance Access
manually using a command-line tool
27 March 2015 41
Alliance Access 7.1
Customers can restore configuration data manually either from the Alliance Web Platform SE
and Alliance Workstation, or using a command-line tool.
13.3.2 Operational Data Archival

Description
Customers can only backup the operational data (messages and events) when these messages
and events have been flagged as archived. The archival is therefore a mandatory prerequisite
to the backup of operational data.
The archival function, applicable to the messages and events, flags a whole day of messages or
events as archived, ensuring that these messages or events cannot be further modified. The
archived messages and events remain stored in the database. The configuration data backup
function must be used to remove the messages and events from the database when needed.
For messages, a day can only be archived when all messages for this day are completed.
Activation
The archival works by specifying the number of active days to keep in the database. All days of
messages and events beyond these active days are flagged as archived.
Customers can activate the operational data archival using either of the following options:
13.3.3 Operational Data Backup and Restore

Description
Customers can store operational data into an external media for future consultation, possibly
using a later release of Alliance Access. In order to consult the operational data backups,
customers must first use the Restore function of Alliance Access to restore the backups into
Alliance Access.
The operational data backup is available as two separate tools, one to back up the data and
another tool to restore the data.
The archiving granularity is by day. That is customers archive a full active day and the complete
day must be restored.
To back up a message, the message must first be marked as archived indicating that this
message cannot be further modified. See "Operational Data Archival" on page 42 for more
details.
Due to this archival constraint, the operational data backup is not suitable to maintain a real-
time backup of live transactions. A message must be completed before being archived and
backed up.
Optionally, the backup function can also be used to physically remove the messages and
events from the database. It is the only means for a customer to remove old operational data
and to control the size of the database.
System Management
Activation
Customers can activate the operational data backup using either of the following options:

Customers can restore operational data manually either from the Alliance Web Platform SE and
Alliance Workstation, or using a command-line tool.
13.3.4 Online Database Backup

Description
The on-line database backup is a required element of the Database Recovery function. This
function is available only through the Database Recovery licence option.
The administrator must configure the automatic on-line backup of the database. This operation
makes use of the embedded Oracle database features to generate, on two separate disks, a
real-time backup of the database activity.
The on-line backups are meant to be used solely with the Recovery function of the Database
Recovery, see "Database recovery" on page 44, and intended to enable customers to restore
the whole Alliance Access database, including the operational data (messages and events)
without any data loss.
Activation
Customers can activate the on-line database backup using either of the following options:
automatically through the Database Recovery configuration functions of Alliance Access
27 March 2015 43
Alliance Access 7.1
14 Resilience
Options available to customers
SWIFT recommends that customers configure the Alliance Access operational environment for
increased resilience.
The resilience options available to customers are as follows:
database recovery option
high-availability cluster software
hosted database
These options are intended to protect software and data, and they minimise the downtime in the
event of a failure.
Automatic restart
If there is a failure of a system on which Alliance Access operates, then the automatic restart
option restarts Alliance Access automatically when the system recovers.
Automatic switchover
Customers can configure Alliance Access to switch automatically between a primary and three
secondary Alliance Gateway or Alliance Remote Gateway connections. This switchover can
occur if one of the connections between Alliance Access and the Alliance Gateway or the
Alliance Remote Gateway fails.
Manual switchover
If the active Alliance Access system fails, then the user can manually switch to a cold backup
system. The customer must install a backup system on which traffic has to be manually re-
started. There is no automatic takeover mechanism. If recovery from a cold backup is
necessary, then the user can restore the database from the live system to the backup system.
Database recovery
The customer can activate the database recovery licence option to increase the system
resiliency, covering the situation where a major incident results in the unavailability of the
primary Alliance Access database. Once activated and configured, customers can use database
recovery to resume operations on a backup Alliance Access system. When the mirror and
backup disks are fully available, this results in no data loss.
The recovery relies on the database backups and transactions archives that Alliance Access
automatically maintains. The customer invokes a database recovery command to restore the
database content on a backup Alliance Access system up to the exact state prior to the incident.
Two recovery models exist:
Full recovery
This model covers a local database loss. The full data from the mirror disk and backup disk is
available. The restored system is up to date, there is no loss of data.
Partial recovery
This model supports a remote disaster site recovery. Some data on the mirror/backup disk is
missing. This is usually due to asynchronous copy of these disks. In this case, recovery is
Resilience
possible up to the last committed transaction. A repair service exists to ensure a consistent
recovery of the database.
High-availability and cluster solutions

High-availability environments or cluster solutions use specific software. SWIFT cannot qualify
all of the configurations available and therefore does not support all configurations. SWIFT
provides support for cluster solutions for Alliance Access that run with Remote Adapter.
IBM AIX platform

SWIFT has qualified Alliance Access to operate in the IBM PowerHA (previously called High-
Availability Cluster Multi-Processing, HACMP) environment on AIX.
HACMP is based on the use of two separate processors that have dual LAN connections and
shared external mirrored disks. SWIFT tests this integration package for each new release of
Alliance Access. Customers that have purchased this option receive this integration package
and the installation documentation at each new release of Alliance Access.
Oracle Solaris platform

With SWIFT's agreement and co-operation, Oracle has developed and tested the Oracle
Cluster Agent for Alliance Access. Customers can find more information about this solution
on www.oracle.com.
Microsoft Windows Server platform

SWIFT did not use cluster solutions during the qualification of its products on Windows
Server. There is also no agreement with a third party for specific co-operated support of a
third-party solutions. Nevertheless, SWIFT supports its products running on clustered
Windows Server environments in alignment with Knowledge Base Tip 1212959.
Red Hat Enterprise Linux platform

SWIFT did not use cluster solutions during the qualification of its products on Linux. There is
also no agreement with a third party for specific co-operated support of a third-party
solutions. Nevertheless, SWIFT supports its products running on clustered Linux
environments in alignment with Knowledge Base Tip 1212959.
Hosted database
The hosted database model is an installation option of Alliance Access supporting the
configuration of the Alliance Access database on an Oracle instance supplied and managed by
the customer. The Alliance Access software is installed on a dedicated server system, including
standard Oracle client software to handle the connectivity between the Alliance Access server
and the Oracle server. In this case, the maintenance and backup of the Oracle environment is
the sole responsibility of the customer.
27 March 2015 45
Alliance Access 7.1
15 Standalone Alliance Access

Overview
The Standalone Access is a specific configuration of Alliance Access for message entry and
repair. Customers can activate and configure a Standalone Access with a licence option, also
referred to as Standalone system for message Entry and Repair.
The Standalone Access has no direct connection to SWIFTNet. It relies on the services of
another standard Alliance Access system connected to SWIFTNet to exchange messages.
Other than this specific connectivity configuration, the Standalone Access provides the same
features and functions of a standard Alliance Access with similar desktop access but without
back-office integration applications.
The communication between the Standalone Access and the other Alliance Access system
connected to SWIFTNet is supported over IBM WebSphere MQ, using the MQHA adapter.
Application Back-office Desktop Desktop

Integration
Integration Application Access Access
Messaging
Software Alliance Access MQ Alliance Access
Standalone Access licence
Communications Alliance
Software Gateway Alliance Remote Gateway
Alliance Gateway
Network
Connection
FIN
InterAct SWIFTNet
FileAct
D0540200
Message flows
This configuration supports the local entry of messages. The messages are created and
managed locally on the Standalone Access and sent over the MQ link, through an MQHA
message partner.
For this entry function, the Standalone Access can receive network acknowledgement over this
MQ link and reconcile these acknowledgements with the original message.
The Standalone Access also supports the repair function, whereby when receiving a network
acknowledgement message (usually a negative one), it creates the associated message
(assuming to original message is provided with the network acknowledgment).
Standalone Access can also receive incoming SWIFT messages from the MQ link.
Standalone Alliance Access
Functionality
The Standalone Access supports MT, MX and FileAct messages.
Note Message repair is not supported for FileAct.
The activation of the Standalone Access licence disables the connection to SWIFTNet and
enables the reconciliation of network acknowledgements and messages entry and repair
functions.
The Standalone Access mandates the use of MQHA (and the XMLv2 format) to connect to the
other Alliance Access connected to SWIFTNet.
The Standalone Access does not support the management of RMA authorisations. These
authorisations must still be managed on the other Alliance Access system connected to
SWIFTNet. The Standalone Access supports the import of RMA authorisations and the optional
validation of created messages against these authorisations. The Standalone Access is not
intended for further integration with back-office systems and does not support the Integration
Platform licence option.
27 March 2015 47
Alliance Access 7.1
16 Third-Party Software
Third-party software embedded in Alliance Access and in Alliance Web Platform Server-
Embedded
Alliance Access and Alliance Web Platform SE include embedded third-party software, in whole
or in part, and no other use of the third-party software is allowed. For all commercial
components licence fees due to the third-party software providers are part of the Alliance
Access and Alliance Web Platform SE licence and maintenance fee. Details regarding
embedded third-party software are displayed during the installation, and can be found in the
Installation Notice provided as part of the software installer.
Ordering
17 Ordering
Order SWIFT services and products
To use SWIFT services and products, a customer must subscribe to, or order, the relevant
services and products.
Related information
For information about SWIFT's online ordering facility and how to order, see www.swift.com/
ordering.
Export restrictions
Due to export control and other sanctions programmes, Alliance Access may not be supplied or
made available to certain customers. If you have any questions about your particular status
regarding the various sanctions programmes, then contact your local Customer Support Centre.
27 March 2015 49
Alliance Access 7.1
18 Support
Support for SWIFT customers
By default, SWIFT is the single point of contact to report all problems and queries that relate to
SWIFT services and products. Support is available to all SWIFT customers.
Individuals within a customer organisation must register to use the Support service.
The different services that SWIFT offers as part of the support packages and the procedure to
order support are described at www.swift.com > Support > Support services > Support offer
overview.
Support for a customer's custom code

Support for a customer's custom code related to Alliance Access Integration Platform may be
obtained from SWIFT under a separate optional contract. For more information, customers can
contact their SWIFT account manager.
Related information
For more information about Support services, see the service description related to the
applicable support package.
Roles and Responsibilities
19 Roles and Responsibilities
19.1 Alliance Access Licence

Licence terms
Subject to the applicable licence terms set out from time to time in this service description and
other relevant SWIFT contractual documentation, SWIFT grants the customer a non-exclusive
and non-transferable right to use Alliance Access as permitted under the Alliance Access base
licence and any options and extensions subscribed to by the customer.
Alliance Access base licence

Each Alliance Access base licence must have, at minimum, one active SWIFT destination (BIC).
The licence band depends upon the average daily volume of traffic for the SWIFT destination
with the highest traffic volume. The Alliance Access base licence includes the usage of the
Relationship Management Application for all the licensed destinations.
Alliance Access base licence automatically includes a certain number of concurrent sessions,
depending on the licence band.
An Alliance Access session is used when an end user or an application authenticates against
Alliance Access as one of following options:
The Alliance Workstation is logged onto Alliance Access
A Web Platform session is logged onto Alliance Access

Multiple sessions can potentially be used on the same desktop when multiple Internet
Explorer windows are opened on the same desktop. Each Internet Explorer windows requires
its own session.
A third-party application, using the Web Services, is authenticated against Alliance Access
An Alliance Access base licence automatically includes the entitlement to download from
www.swift.com: patch updates, Application Service Profiles, Standards Deployment Packages,
and the Alliance Bank File.
Note Each destination has its own band.
Test and Training destinations are free of charge and their traffic is not taken
into account for the band calculation.
The daily average traffic is calculated on a monthly basis, taking into account the
number of SWIFT working days in the month under consideration.
When the Alliance Access base licence is installed on multiple production

systems, the destination band is determined by the total live traffic of that
destination on all production systems.
Software included in the base licence

The Alliance Web Platform Server-Embedded (SE) software is delivered with the Alliance
Access software.
This product includes the software required to deploy the Alliance Web Platform, including an
embedded application server. The customer does not require additional third-party software to
use Alliance Web Platform Server-Embedded.
27 March 2015 51
Alliance Access 7.1
Alliance Workstation is also delivered with the Alliance Access software, except for the Linux
version.
The Alliance Access base licence includes the right for the customer to install and use Alliance
Workstation and Alliance Web Platform SE on as many systems as reasonably necessary to
support the number of licensed concurrent sessions. In case multiple production systems are
used, the sum of users connecting to the different production systems cannot exceed the
number of licensed concurrent sessions.
Customers can use all the graphical services provided by Alliance Web Platform SE.
Software not included in the base licence

The Alliance Access base licence does not include a licence for Alliance Gateway or Alliance
Remote Gateway. As applicable, the customer must order a separate licence for Alliance
Gateway or Alliance Remote Gateway. When using the MQ Host Adapter, customers must
provide an appropriately licensed copy of the IBM WebSPhere MQ Client software to be
installed on the Alliance Access server.
Installation options
For each Alliance Access base licence, customers can choose any or all of the following
installation options:
up to three production systems (all to be located on the same campus)
up to three test systems potentially deployed in different campuses
up to three contingency systems potentially deployed in different campuses

All systems that SWIFT permits under the Alliance Access base licence are subject to a single,
fixed maintenance fee.
Note Standalone systems are counted as separate systems.
Hosted database model

The hosted database installation model is available as a licence option.
The Alliance Access base licence permits customers to use the hosted installation option in test
and training mode without ordering an additional licence option. However, customers must order
and activate this licence option to use the hosted installation option in production.
Licence bands
The daily volume of live traffic sent and received determines the band of a SWIFT destination.
One FIN message (MT) or one InterAct message (MX) or one 10,000 characters chunk of a
FileAct message (file) is counted as one unit of traffic. For more information, customers can
contact their SWIFT Account Manager.
Band levels
Band Average daily live traffic sent and received

(1 MT, 1 MX, or 10,000 characters of a file: all
counted as 1 unit)
Band -1 Up to 250 units
Band 0 Up to 500 units
Band 1 Up to 1,000 units
Band Average daily live traffic sent and received

(1 MT, 1 MX, or 10,000 characters of a file: all
counted as 1 unit)
Band 9 More than 500,000
Band upgrades
The Alliance Access base licence band is the highest of the bands of all the SWIFT
destinations of the Alliance Access base licence. As the traffic increases over time, the band
of a SWIFT destination requires an upgrade whenever the volume threshold of the next band
is exceeded. Consequently, the Alliance Access base licence requires an upgrade whenever
the highest of the SWIFT destination bands exceeds the Alliance Access base licence band.
Once per year, SWIFT recalculates the bands of the SWIFT destinations and the Alliance
Access base licences, based on the traffic volumes of the previous 12 months. The total
traffic volume sent and received during that period is divided by the number of working days
in the period.
Band downgrades
If the traffic sent and received on a SWIFT destination decreases below the level of the
current band, then the customer can order a band downgrade. The customer can also order
a band downgrade if the highest band of the SWIFT destinations belonging to the base
licence decreases.
Additional licence options

Customers can order additional licence options (not included in the Alliance Access base
licence). For a complete list of available options, customers can contact their SWIFT Account
Manager.
Alliance Access licence extensions

A customer may order Alliance Access base licence extensions in respect of additional
production, test, and contingency systems. Any additional production systems permitted under a
base licence extension can be spread over different buildings but still within the same campus.
Licence extensions are linked to the related Alliance Access base licence, and cannot be
transferred separately from that base licence.
Standalone Access
The use of Standalone Alliance Access is available as a licence option.
The licence option grants customers with the following installation options:
up to three production systems (all to be located in the same campus)
up to three test systems potentially deployed in different campuses
27 March 2015 53
Alliance Access 7.1
up to three contingency systems potentially deployed in different campuses
Note Standalone systems are counted as separate systems, independent from the base
Alliance Access systems.
Customers can order additional licence options specifically for Standalone Alliance Access. For
a complete list of available options, customers can contact their SWIFT Account Manager.
Operating system swap

The swap of operating system is available as a chargeable option. For more information,
customers can contact their SWIFT Account Manager.
19.2 SWIFT's Roles and Responsibilities

General
SWIFT's roles and responsibilities with regard to Alliance Access are set out in this service
description and other relevant SWIFT contractual documentation, typically, the SWIFT General
Terms and Conditions.
Delivery
SWIFT may supply Alliance Access in any form or any medium, including but not limited to DVD
or download through the Internet.
New releases
SWIFT makes new releases of Alliance Access available in accordance with the development of
other SWIFT services and products.
For the latest information about new releases, customers must consult the SWIFT Release
Timeline, the SWIFTNet and Alliance Release Policy, and related information at www.swift.com
> Products & Services > Release timeline.
Liability for certain matters

SWIFT shall not be responsible or have liability for problems or issues arising as a result of any
of the following:
any unauthorised or improper use of Alliance Access Integration Platform
software or custom code developed, or other services provided, by SWIFT Consulting

Services unless specifically contracted under a separate optional agreement (see "SWIFT
Consulting Services" on page 55)
use of services or products (including any software or custom code) that SWIFT has not
supplied for use in connection with Alliance Access Integration Platform
an act, fault, or omission of the customer or a third party for which SWIFT is not responsible
a defect reported to SWIFT and identified as being a configuration issue
force majeure
SWIFT Consulting Services

Should SWIFT provide consulting services related to Alliance Access Integration Platform,
SWIFT's obligations and responsibilities will be governed by the applicable service proposal and
the related SWIFT Consulting Terms and Conditions.
Liability concerning third-party components

SWIFT cannot take any liability for problems caused by components added to the software that
are provided by third parties. This includes but is not limited to third-party components contained
in the Alliance Developer Kit, Integration Platform packages or any data that is used by an
Integration Platform package, Web Services or scripted commands.
19.3 Customer's Roles and Responsibilities

General
The customer's roles and responsibilities with regard to Alliance Access are set out in this
service description and other relevant SWIFT contractual documentation, typically, the SWIFT
General Terms and Conditions.
Changes to customer infrastructure

The customer must inform SWIFT at least three weeks in advance of any change to its
infrastructure that may impact the provision of SWIFT services and products, including Alliance
Access.
Installation
The customer has the following options for the installation of Alliance Access:
install and configure itself
request SWIFT to perform the installation
request a third party (typically a SWIFT Certified Specialist) to perform the installation
If the customer does not have all necessary expertise or resources available internally, then
SWIFT strongly recommends that the customer requests either SWIFT or third party such as a
SWIFT Certified Specialist to perform the installation of Alliance Access. For more information
about the installation services offered by SWIFT or a SWIFT Certified Specialist, see the
Software Implementation Service Overview.
Integration solution definition and testing

SWIFT Consulting Services and the customer must work together to analyse business needs
and to define requirements for the customer's integration solution. Depending on the needs
identified, SWIFT Consulting Services develops any custom logic that is necessary. The
customer is responsible for testing that the integration solution behaviour is suitable for the
needs that were identified.
Installation and implementation

SWIFT Consulting Services performs the installation and provides assistance for the
implementation project and transfers the knowledge to the customer. The customer ultimately
bears complete responsibility for design and use of integration solutions in their environment.
27 March 2015 55
Alliance Access 7.1
Processes and procedures

It is the customer's responsibility to implement the appropriate business processes and system
configuration that ensure proper message flow that is in line with their business needs and
security requirements.
Intrusion testing
It is not permitted to perform intrusion testing on SWIFT services and systems. SWIFT has its
own intrusion testing programme (which is covered in a third-party assurance report).
Regression testing for third-party components

It is the customer's responsibility to run sufficient regression tests when Alliance Developer Kit
or the custom logic built using Integration Platform components are used on an upgraded
version of Alliance Access. It is the customer's responsibility to run sufficient regression tests
when installing Deployment Packages published by third parties on MyStandards.
Contractual Framework
20 Contractual Framework
SWIFT General Terms and Conditions
Together with this service description, the SWIFT General Terms and Conditions govern the
provision and the use of Alliance Access.
For the latest available version of the SWIFT General Terms and Conditions, see
www.swift.com > About SWIFT > Legal > SWIFT contracts.
27 March 2015 57
Alliance Access 7.1
Legal Notices
Copyright
SWIFT 2015. All rights reserved.
Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order expressly grants
you that right, in which case ensure you comply with any other applicable conditions.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest
available version.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: the SWIFT
logo, SWIFT, SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo, MyStandards, and
SWIFT Institute. Other product, service, or company names in this publication are trade names, trademarks,
or registered trademarks of their respective owners.

Service Description: Alliance Access 7.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Service Description: Alliance Access 7.1

Uploaded by

Copyright:

Available Formats

Connectivity

Alliance Access 7.1

1 Overview of Alliance Access ..................................................................................................................... 6

2 System Requirements ................................................................................................................................... 8

3 SWIFTNet Messaging Services ............................................................................................................... 10

4 Message Formats .......................................................................................................................................... 11

5 Message Validation ...................................................................................................................................... 13

6 Message Management ................................................................................................................................ 15

7 Application Integration ............................................................................................................................... 22

8 Integration with Customer Business Applications ........................................................................ 28

9 Desktop Access ............................................................................................................................................. 31

10 Operator Profile Management ................................................................................................................. 34

11 Correspondent Management ................................................................................................................... 36

12 Relationship Management Application ............................................................................................... 37

13 System Management ................................................................................................................................... 38

13.3 Backup and Restore ............................................................................................................................... 41

15 Standalone Alliance Access .................................................................................................................... 46

16 Third-Party Software .................................................................................................................................... 48

19 Roles and Responsibilities ....................................................................................................................... 51

20 Contractual Framework .............................................................................................................................. 57

SWIFT partners and service bureaux.

Updated information Location

Update to the IPLA section "Alliance Access Integration Platform" on page

Update to the third-party software section "Third-Party Software" on page 48

Deleted information Location

References to MQSA and CAS Throughout the document

the Alliance Web Platform SE documentation set

the Alliance Access documentation set

Alliance Access Release Letter

Alliance Gateway Service Description

Alliance Remote Gateway Service Description

FIN Service Description

the relevant Standards MT Message Reference Guides

the relevant Standards MX Message Definition Reports

the relevant Support Service Description

SWIFT General Terms and Conditions

SWIFTNet Link Service Description

SWIFTNet Service Description

SWIFTNet and Alliance Release Policy

SWIFTNet Resilience Guide

OS Levels and Patches Baseline

1 Overview of Alliance Access

Overview of Alliance Access

Application Back-Office Desktop

Messaging Alliance Access

Monitoring and System

Communications Alliance Gateway

Network Alliance Gateway

configure and manage connections to SWIFTNet messaging services

connect to the customer's internal network and systems

manage RMA authorisations

integrate Alliance Access with back-office systems and applications

configure and control Alliance Access

prepare, send, and receive messages

send and receive files

Memory and disk requirements

the message and file traffic

the amount of archived messages and journal entries

the number of operator sessions

the number of configured message partners

the amount of data kept for Operational Reporting

Connection between the end user and Alliance Access

2.2 Operating System