Sunteți pe pagina 1din 58
Connectivity Alliance Access 7.1 Service Description This service description provides information about the features and

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

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

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 relevant Support Service Description

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

D0540196

File Transfer Workstation Browser MQ SOAP Direct FileAct Web Platform Back-Office Desktop Integration Access
File Transfer
Workstation
Browser
MQ
SOAP
Direct FileAct
Web Platform
Back-Office
Desktop
Integration
Access
Application
IPLA Web Services ADK Application Integration
IPLA
Web Services
ADK
Application
Integration

Messaging

Software

Alliance Access

Profile and Correspondent Management

Monitoring and System Management

Message Management and Routing

RMA

Alliance Remote Gateway Alliance Gateway SWIFTNet
Alliance Remote Gateway
Alliance Gateway
SWIFTNet

Communications

Software

Alliance Gateway

Network

Connection

Gateway Alliance Gateway SWIFTNet Communications Software Alliance Gateway Network Connection FIN InterAct FileAct

FIN

InterAct

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

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.

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.

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

D0540203

File Transfer Workstation Browser MQ IPLA SOAP Web Services Direct FileAct Web Platform ADK Back-office
File Transfer
Workstation
Browser
MQ
IPLA
SOAP
Web Services
Direct FileAct
Web Platform
ADK
Back-office
Application
Desktop
Integration
Integration
Access
Application
Desktop Integration Integration Access Application Alliance Access MT XML File Alliance Gateway Alliance
Alliance Access MT XML File Alliance Gateway Alliance Remote Gateway Alliance Gateway SWIFTNet
Alliance
Access
MT
XML
File
Alliance
Gateway
Alliance Remote Gateway
Alliance Gateway
SWIFTNet

Messaging

Software

Communications

Software

Network

Connection

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.

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.

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)

Web

SE

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.

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

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.

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.

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.

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.

Application Integration

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.

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

Application Integration

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

Alliance Access 7.1

8 Integration with Customer Business Applications

Overview of the connection methods

D0540198

File Transfer Workstation Browser MQ IPLA SOAP Web Services Direct FileAct Web Platform ADK Back-Office
File Transfer
Workstation
Browser
MQ
IPLA
SOAP
Web Services
Direct FileAct
Web Platform
ADK
Back-Office
Application
Desktop
Integration
Integration
Access
Application
Messaging
Alliance Access
Software
Profile and
Correspondent Management
Monitoring and System
Management
Message Management
and Routing
RMA
Communications
Alliance Gateway
Software
Alliance Remote Gateway
Alliance Gateway
Network
Connection
FIN
InterAct
SWIFTNet
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.

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.

Alliance Access 7.1

D0540197

File Transfer Workstation Browser MQ IPLA SOAP Web Services Direct FileAct Web Platform ADK Back-Office
File Transfer
Workstation
Browser
MQ
IPLA
SOAP
Web Services
Direct FileAct
Web Platform
ADK
Back-Office
Application
Desktop
Integration
Integration
Access
Application
Messaging
Alliance Access
Software
Profile and
Correspondent Management
Monitoring and System
Management
Message Management
and Routing
RMA
Communications
Alliance Gateway
Software
Alliance Remote Gateway
Alliance Gateway
Network
Connection
FIN
InterAct
SWIFTNet
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.

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

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.

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.

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

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

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

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

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:

• automatically through the Calendar function of Alliance Access

• manually using a command-line tool

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:

• automatically through the Calendar function of Alliance Access

• manually using a command-line tool

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

• manually using a command-line tool

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.

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.

D0540200

Messaging

Software

Communications

Software

Network

Connection

Back-office Integration Application
Back-office
Integration
Application
Desktop Access
Desktop
Access
Desktop Access
Desktop
Access
Alliance Access Standalone Access licence

Alliance Access Standalone Access licence

Alliance Access Standalone Access licence
Alliance Access Standalone Access licence
Application Integration
Application
Integration
Alliance Access

Alliance Access

Alliance Access
Alliance Gateway
Alliance Gateway

Alliance

Gateway

Alliance Gateway
Alliance Gateway
Alliance Gateway
Alliance Gateway
Alliance Gateway
Alliance Gateway
Alliance Gateway
Alliance Gateway
Alliance Gateway
Alliance Gateway

MQ

Integration Alliance Access Alliance Gateway MQ Alliance Remote Gateway Alliance Gateway SWIFTNet FIN
Alliance Remote Gateway Alliance Gateway SWIFTNet
Alliance Remote Gateway
Alliance Gateway
SWIFTNet

FIN

InterAct

FileAct

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.

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/

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.

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

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.

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

Roles and Responsibilities

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 2

Up to 2,000 units

Band 3

Up to 5,000 units

Band 4

Up to 20,000 units

Band 5

Up to 50,000 units

Band 6

Up to 100,000 units

Band 7

Up to 250,000 units

Band 8

Up to 500,000 units

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

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

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

Roles and Responsibilities

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

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.

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.

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.

Evaluare

Partajare