SWIFTNet Messaging Services

SWIFTNet FINCopy

Service Description
This service description describes the SWIFTNet FINCopy service for the benefit of users of the service, service
administrators, and developers. It describes the features and functions of the service as well as the security and control
aspects. The document also includes the general terms and conditions, the responsibilities and liabilities applicable to
SWIFT, the service administrators, and users.

16 February 2007
SWIFTNet FINCopy

Legal Notices
Copyright
Copyright © S.W.I.F.T. SCRL ("SWIFT"), avenue Adèle 1, B-1310 La Hulpe, Belgium, or its licensors, 2007.
All rights reserved.
You may copy this publication within your organisation. Any such copy must include these legal notices.

Confidentiality
This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside
your organisation without the prior written consent of SWIFT.

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, S.W.I.F.T., the SWIFT logo, Sibos, SWIFTNet, SWIFTAlliance, SWIFTStandards, SWIFTReady, and
Accord are trademarks of S.W.I.F.T. SCRL. Other SWIFT-derived service and product names, including
SWIFTSolutions, SWIFTWatch, and SWIFTSupport are tradenames of S.W.I.F.T. SCRL. SWIFT is the trading
name of S.W.I.F.T. SCRL. Other product or company names in this publication are tradenames, trademarks,
or registered trademarks of their respective owners.

2 Service Description
 Preface

Preface
Contents
This service description describes the SWIFTNet FINCopy Service. It sets out the general terms
and conditions, responsibilities, and liabilities of SWIFT and the users of the SWIFTNet FINCopy
Service.
Although SWIFTNet FINCopy is an extension of SWIFTNet FIN functionality, it is a separate
service. Similarly, this service description is separate from SWIFTNet FIN service publications.

Note This service description, together with the SWIFT General Terms and Conditions and
other relevant service documentation, is an integral part of the contractual
arrangements between SWIFT and its customers for the provision and use of
SWIFTNet FINCopy.

Intended readership
The information is intended for:

• current or prospective SWIFTNet FINCopy users, service administrators, or other users

requiring a good understanding of this SWIFT service

• developers requiring background information about elements of SWIFTNet FINCopy

Readers of this document require a basic understanding of SWIFTNet FIN messaging, as
described in the SWIFTNet FIN Service Description. A brief summary of SWIFTNet FIN messaging
is included in the Introduction of this service description.

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 highlighted as shown in this
example:
SWIFT provides secure, standardised messaging services and interface software to its
customers.

Related documentation
For a better understanding of SWIFTNet FIN messaging, see:

• SWIFTNet FIN Service Description

• SWIFTNet FIN Operations Guide

• SWIFTNet FIN Error Codes

• SWIFTNet FIN Security Guide

• SWIFTNet FIN System Messages

• SWIFT Glossary

• SWIFT Data Retrieval Policy

• SWIFT General Terms and Conditions

• SWIFTSupport Service Description

16 February 2007 3
SWIFTNet FINCopy

• SWIFT Price List

You can find the SWIFTNet Phase 2 Planning Guide and other SWIFTNet Phase 2 information
on www.swift.com > Products & Services > Initiatives > SWIFTNet Phase 2

Significant changes since the March 2005 edition

Modifications due to SWIFTNet Phase 2 migration.
Change of name from SWIFTNet FIN Copy to SWIFTNet FINCopy.

4 Service Description
 Table of Contents

Table of Contents

1 Introduction ....................................................................................................................................................... 9
1.1 SWIFTNet and SWIFTNet FIN Overview .............................................................................................. 9
1.2 SWIFTNet FINCopy Overview ................................................................................................................ 9
1.3 How SWIFTNet FINCopy Works .......................................................................................................... 10
1.4 Implementing SWIFTNet FINCopy ....................................................................................................... 12
1.4.1 Service Administrators ......................................................................................................... 12
1.4.2 SWIFTNet FINCopy Users .................................................................................................. 12
1.5 Support for SWIFTNet FINCopy ........................................................................................................... 13
1.5.1 Service Administrators ......................................................................................................... 13
1.5.2 SWIFTNet FINCopy Users .................................................................................................. 13

2 Features and Functions ............................................................................................................................. 15

2.1 SWIFTNet FINCopy Service Parameters ............................................................................................ 15
2.2 SWIFTNet FINCopy Service Modes .................................................................................................... 16
2.2.1 Y-Copy Mode ......................................................................................................................... 17
2.2.1.1 Monitoring Messages ........................................................................................... 19
2.2.1.2 Optional Sender Notification ................................................................................ 20
2.2.1.3 Optional Receiver Notification .............................................................................. 21
2.2.2 T-Copy Mode ......................................................................................................................... 21
2.2.3 Bypass Mode ......................................................................................................................... 22
2.3 Service States .......................................................................................................................................... 22
2.4 Service Messages ................................................................................................................................... 23
2.4.1 MT 096 SWIFTNet FIN Copy Service to Service Administrator Message ................... 23
2.4.2 MT 097 SWIFTNet FINCopy Message Authorisation/Refusal Notification .................. 25
2.4.3 MT 028 SWIFTNet FINCopy Message Status Request ................................................ 27
2.4.4 MT 029 SWIFTNet FINCopy Message Status Report .................................................... 28
2.4.5 MT 030 Cut-off Time Reconciliation Request ................................................................... 28
2.4.6 MT 050 Cut-off Time Reconciliation Report ...................................................................... 29

3 Security and Control .................................................................................................................................... 31

3.1 Closed User Groups ............................................................................................................................... 31
3.2 Double Authentication ............................................................................................................................ 31

4 Service Administrator Responsibilities .............................................................................................. 35

4.1 Implementation ........................................................................................................................................ 35
4.1.1 Procedure ............................................................................................................................... 35
4.1.1.1 Service Administrator Agreement and Project Plan ............................................. 35
4.1.1.2 Service Profile ...................................................................................................... 35
4.1.1.3 Operations Guide ................................................................................................. 37
4.1.2 Additional SWIFTNet FINCopy Server Destinations ....................................................... 37
4.1.3 SWIFTNet FIN Interfaces ..................................................................................................... 37
4.2 Operational ............................................................................................................................................... 37
4.3 General Responsibilities ........................................................................................................................ 39

16 February 2007 5
SWIFTNet FINCopy

5 SWIFTNet FINCopy User's Responsibilities ..................................................................................... 41

5.1 Implementation ........................................................................................................................................ 41
5.1.1 Procedures ............................................................................................................................. 41
5.1.2 SWIFTNet FIN Interface ....................................................................................................... 41
5.2 Operational ............................................................................................................................................... 42
5.2.1 Sender's Perspective ............................................................................................................ 42
5.2.2 Receiver's Perspective ......................................................................................................... 44

6 Relationship between SWIFTNet FINCopy and SWIFTNet FIN ................................................. 47

6.1 Message Retrievals ................................................................................................................................ 47
6.2 Message Flow Integrity .......................................................................................................................... 47
6.2.1 SWIFTNet FINCopy Service Trigger Mechanism ............................................................ 47
6.2.2 Delivery Monitoring and Message Abort Notifications .................................................... 48
6.2.3 SWIFTNet FINCopy Abort Notification .............................................................................. 48
6.2.4 Duplicate Message Avoidance ............................................................................................ 49
6.2.5 Message Cancellation .......................................................................................................... 49
6.2.6 Payment Release Information ............................................................................................. 49
6.2.7 Message Status Reporting to Sender ................................................................................ 50
6.2.8 SWIFTNet FINCopy Service Fallback ............................................................................... 50
6.3 Test and Training .................................................................................................................................... 51

7 Ordering ............................................................................................................................................................ 53

8 SWIFT General Terms and Conditions and Liability ..................................................................... 55

8.1 Application of the SWIFT General Terms and Conditions ................................................................ 55
8.2 SWIFT Liability ......................................................................................................................................... 55
.Appendix A SWIFTNet FINCopy Service Profile ..........................................................................................57
A.1 SWIFTNet FINCopy Service Profile ..................................................................................................... 57
A.2 SWIFTNet FINCopy Service Profile Parameters ............................................................................... 58
A.2.1 SWIFTNet FINCopy Service Code ..................................................................................... 58
A.2.2 Live Service Flag ................................................................................................................... 58
A.2.3 Service Administrator Destination (CID) ............................................................................ 58
A.2.4 Authentication Mode ............................................................................................................. 58
A.2.5 Digital Signature Generation ............................................................................................... 59
A.2.6 Full Copy Flag ........................................................................................................................ 60
A.2.7 Currency Code ....................................................................................................................... 61
A.2.8 MT 012 Y-Copy Sender Notification .................................................................................. 61
A.2.9 Message Types Selected for Copying ............................................................................... 61
A.2.10 SWIFTNet FINCopy Service Mode .................................................................................... 61
A.2.11 SWIFTNet FINCopy Fallback Service Mode .................................................................... 62
A.2.12 SWIFTNet FINCopy Server Destinations .......................................................................... 62
.Appendix B Case Studies for SWIFTNet Phase 1 .......................................................................................63
B.1 Purpose of this Appendix ....................................................................................................................... 63
B.2 Transaction Profile .................................................................................................................................. 64
B.3 Messages, Y-Copy Mode: Authorised Payment ................................................................................ 65

6 Service Description
 Table of Contents

B.4 Messages, Y-Copy Mode: Rejected Payment .................................................................................... 70

B.5 Messages, Fallback to Bypass Mode .................................................................................................. 74
B.6 Messages, T-Copy Mode ....................................................................................................................... 76
.Appendix C Case Studies for SWIFTNet Phase 2 .......................................................................................81
C.1 Purpose of this Appendix ....................................................................................................................... 81
C.2 Transaction Profile .................................................................................................................................. 82
C.3 Messages, Y-Copy Mode: Authorised Payment ................................................................................ 83
C.4 Messages, Y-Copy Mode: Rejected Payment .................................................................................... 88
C.5 Messages, Fallback to Bypass Mode .................................................................................................. 92
C.6 Messages, T-Copy Mode ....................................................................................................................... 94
.Appendix D Service Administrators Operations Guide ...........................................................................99
D.1 General ..................................................................................................................................................... 99
D.1.1 Scope of this Appendix ........................................................................................................ 99
D.2 Definition of Procedures ......................................................................................................................... 99
D.2.1 SWIFTNet FINCopy Service: Normal Procedures ........................................................... 99
D.2.2 SWIFTNet FINCopy Service: Emergency Procedures ................................................. 100
D.2.2.1 SWIFTNet FINCopy Service: Unforeseen Critical Emergency Events .............. 100
D.2.2.2 SWIFTNet FINCopy Service: Planned Contingency Testing ............................. 100
D.3 Data Maintenance ................................................................................................................................. 101
D.3.1 Ordering and Data Maintenance ...................................................................................... 102
D.4 Processes and Procedures .................................................................................................................. 103
D.4.1 P1: Order from a SWIFTNet FINCopy User approved by the Service Administrator,
to COS by Form ................................................................................................................... 103
D.4.2 P2: Order from a Service Administrator to COS by Form ............................................. 103
D.4.3 P3: Order from a Service Administrator to Market Infrastructures Service
Management by Form ........................................................................................................ 104
D.4.3.1 P3: To Define or Modify SWIFTNet FINCopy Service Parameters .................... 104
D.4.3.2 P3 - To order telephone authentication cards .................................................... 105
D.4.3.3 P3: To Open the SWIFTNet FINCopy Service ................................................... 105
D.4.4 P4: Problem Report to CSC .............................................................................................. 105
D.4.5 P5: Emergency Request from the Service Administrator to CSC by Authenticated
Telephone Call ..................................................................................................................... 106
D.4.6 P6: Problem Report from a SWIFTNet FINCopy User to the Local Settlement Help
Desk by Telephone ............................................................................................................. 106
D.5 Stress Testing SWIFTNet FINCopy ................................................................................................... 107
D.6 Telephone Authentication Procedure ................................................................................................. 107
D.6.1 Telephone Authentication Cards ...................................................................................... 108
D.6.1.1 Introduction ........................................................................................................ 108
D.6.1.2 Definitions .......................................................................................................... 108
D.6.1.3 Administration .................................................................................................... 108
D.6.1.4 Ordering Procedures .......................................................................................... 109
D.6.1.5 Operational Procedures ..................................................................................... 109
D.6.1.6 Troubleshooting ................................................................................................. 111
D.7 Forms ...................................................................................................................................................... 112
D.7.1 SWIFTNet Service Profile .................................................................................................. 112

16 February 2007 7
SWIFTNet FINCopy

D.7.2 Emergency Request Confirmation ................................................................................... 113

D.7.3 SWIFTNet Subscription Form ........................................................................................... 113
D.7.4 SWIFTNet Terminate Subscription Form ........................................................................ 113

8 Service Description
 Introduction

1 Introduction
General
This chapter introduces the SWIFTNet FINCopy Service. It explains:

• what SWIFTNet FINCopy is

• how SWIFTNet FINCopy fits within SWIFTNet FIN messaging

• how and why customers use SWIFTNet FINCopy

• how SWIFTNet FINCopy works

• how customers implement SWIFTNet FINCopy

SWIFTNet FINCopy is an independent and separate service that extends SWIFTNet FIN
functionality. For more information about the SWIFTNet FIN service, see the SWIFTNet FIN
Service Description, the SWIFTNet FIN Operations Guide, SWIFTNet FIN Error Codes, and the
SWIFTNet FIN System Messages.

1.1 SWIFTNet and SWIFTNet FIN Overview

SWIFTNet
SWIFTNet is a secure, dedicated, global communication network that supports a range of financial
messaging services, which includes the SWIFTNet FIN store-and-forward message-processing
service.

SWIFTNet FIN
SWIFTNet FIN provides users with a wide range of message types for transaction and information
processing and settlement.
SWIFTNet FIN messages consist of structured headers, text, and trailers, and conform to
internationally accepted standards. SWIFT protects the confidentiality, integrity, and authenticity
of SWIFTNet FIN messages as described in the SWIFTNet FIN Service Description.

1.2 SWIFTNet FINCopy Overview

Introduction
SWIFTNet FINCopy is a message duplication service. SWIFT developed SWIFTNet FINCopy to
assist financial communities in implementing centralised systems, for example, Real-Time Gross
Settlement (RTGS) or netting systems.
RTGS and netting systems respond to risk management needs by separating funds transfers into:

• information processing between the sending institution and the receiving institution

• funds settlement, in which both institutions maintain accounts in the books of a controlling
institution

16 February 2007 9
SWIFTNet FINCopy

The service administrator, acting as a third party in the transfer process, must do the following:

• capture sufficient elements of the funds transfer to perform the settlement and control function

• ensure that its intervention does not affect the prompt delivery of information to the receiving
institution, which would cause additional risk

SWIFTNet FINCopy
SWIFTNet FINCopy, in combination with SWIFTNet FIN, provides the service administrator with
a simple, flexible, and secure way to monitor and control financial transactions. SWIFTNet
FINCopy uses the facilities of SWIFTNet FIN, enhanced with a copy of selected information to the
third party. This service can be used to clear, net or settle high-value payments, securities, and
other financial transactions.
It is a Store-Copy-(Authorise)-and-Forward facility for users that participate in a Closed User Group
(CUG).
A SWIFTNet FINCopy CUG comprises:

• users that participate in the SWIFTNet FINCopy CUG

• a service administrator that manages clearing, netting, or settlement tasks

The SWIFTNet FIN interface of the service administrator usually connects with a settlement or
other clearing system, which authorises the message delivery to the intended receiver. The
decision to authorise and enable delivery is based on the following elements:

• the actual message contents

• dynamic business data about the parties involved, for example, the sender's account balance

• multilateral preagreements within the user community

• any combination of all or part of the preceding items

1.3 How SWIFTNet FINCopy Works

Copy modes
A normal SWIFTNet FIN relationship is between the sender and the receiver of a SWIFTNet FIN
message. SWIFTNet FINCopy involves a third party, a service administrator, in message flows,
or modes, known as Y-Copy and T-Copy.
These illustrations show the information flows for:

• normal SWIFTNet FIN service (Figure 1)

• SWIFTNet FINCopy Y-Copy and T-Copy modes (Figure 2)

10 Service Description
 Introduction

Figure 1: SWIFTNet FIN service Information Flow

SWIFTNet FIN
Messaging
Sender Service Receiver

D0110001
Figure 2: SWIFTNet FINCopy service Information Flow

Full message
Full message information
information + Authorisation detail

Sender Receiver

Full or partial
information
copied
Authorisation
Y -Copy
mode

Service Administrator

Full message information

Sender Receiver

Full or partial
information
copied
T -Copy
mode
D0110002

Service Administrator

16 February 2007 11
SWIFTNet FINCopy

The sending institution uses SWIFTNet FIN to prepare its message for transmission to the receiver,
in the usual way. The sender adds a service code that indicates that it requires a copy of the
message, and then transmits the message.
In Y-Copy mode, SWIFTNet FINCopy intercepts the SWIFTNet FIN message and copies some
or all of the information to a service administrator. SWIFTNet FINCopy holds the message in a
temporary queue until the service administrator sends the appropriate authorisation or rejection.
If the message is authorised, SWIFTNet FIN forwards it for delivery to the receiver, together with
the authorisation code. Optionally, the service administrator can add information for the sender or
the receiver of the original message, or both. If the message is rejected, SWIFTNet FIN aborts the
message and notifies the sender.
In T-Copy mode, SWIFTNet FINCopy copies some or all of the information to a service
administrator. The SWIFTNet FIN message is not held in a temporary queue, but is queued for
delivery to the intended recipient in the normal way. The service administrator can advise the
sender and receiver of the status of the transaction by separate messages after the event.
The general principles of SWIFTNet FIN, as described in the SWIFTNet FIN Service Description
and the SWIFTNet FIN Operations Guide, apply to all messages involved in SWIFTNet FINCopy.

1.4 Implementing SWIFTNet FINCopy

1.4.1 Service Administrators
Aspects of implementation
Service administrators may implement SWIFTNet FINCopy as part of a larger project, for example,
to create or enhance a clearing, netting, or settlement system. For this, the service administrator
may need to register as a SWIFT user, install a SWIFTNet FIN interface, and connect to SWIFTNet
FIN.
The SWIFTNet FINCopy implementation procedure consists of the following aspects:

• administrative - The service administrator establishes a CUG, determines the message types
and fields that SWIFTNet FINCopy must copy, and decides which service code to use.

• practical - The service administrator ensures that its SWIFTNet FIN Interface can receive
copies of messages and send authorisations and rejections.

• legal - The service administrator establishes a SWIFTNet FINCopy service agreement with
SWIFT. The service administrator also establishes an agreement framework with its users (that
is, the SWIFTNet FIN users that participate in the CUG).

1.4.2 SWIFTNet FINCopy Users

SWIFTNet FINCopy implementation
To implement SWIFTNet FINCopy, the user must do the following:

• Confirm with its SWIFTNet FIN interface supplier that the interface supports SWIFTNet
FINCopy.

• Establish agreements with the service administrator and with SWIFT to use the SWIFTNet
FINCopy service. The user must use the SWIFTNet Service Subscription Form to confirm the
agreement to comply with SWIFT's requirements for the use of SWIFTNet FINCopy.

12 Service Description
 Introduction

• Enter a three-character service code in the optional field 103 in block 3 to identify the SWIFTNet
FINCopy Service.
SWIFTNet FINCopy supports access to multiple services by the same user, by using a unique
code to identify each service.

• Automated message generation systems must insert field 103 in the user header block when
they create the SWIFTNet FIN message to be copied.
Some SWIFTNet FIN Interface implementations insert field 103 into the header block
automatically. Users that participate in a SWIFTNet FINCopy CUG can confirm details with
individual suppliers.
Field 103 is located in the user header block as follows:
{3:{103:<service-code>}{113:<banking-priority>}{108:<MUR>}}

Note Other fields may be present in the user header block. For a full description of the user
header format, see SWIFTNet FIN System Messages.

1.5 Support for SWIFTNet FINCopy

1.5.1 Service Administrators
Support for service administrators
During the implementation phase, SWIFT helps the service administrator to define the service
parameters and manage the SWIFTNet FINCopy Closed User Group (CUG). See: "Features and
Functions" on page 15.
When the SWIFTNet FINCopy service is operational, SWIFT manages the SWIFTNet FINCopy
CUG, based on input from the service administrator.
SWIFT provides operational support for SWIFTNet FINCopy in the same way as it provides support
for SWIFTNet FIN. For information about the operational support for SWIFTNet FIN, see the
SWIFTSupport Service Description.

1.5.2 SWIFTNet FINCopy Users

Support for SWIFTNet FINCopy users
The SWIFTNet FIN support available to SWIFTNet FIN users is also available to users that
participate in a SWIFTNet FINCopy CUG.
SWIFT implements the SWIFTNet FINCopy CUG and the service administrator enrols or
withdraws users in the SWIFTNet FINCopy CUG. The service administrator generally provides
additional administrative support to the users that participate in the CUG, for example, the local
settlement helpdesk.

16 February 2007 13
SWIFTNet FINCopy

14 Service Description
 Features and Functions

2 Features and Functions

General
This chapter describes the features and functions of the SWIFTNet FINCopy Service. It covers
the following topics:

• the SWIFTNet FINCopy service parameters

• SWIFTNet FINCopy service modes

• message flows within Y-Copy and T-Copy modes, including optional sender notification in Y-
Copy mode

• SWIFTNet FINCopy service states

• the structure and use of SWIFTNet FINCopy Service messages MT 096 and MT 097

• the use of SWIFTNet FINCopy Service messages MT 028 and MT 029

• the use of SWIFTNet FIN system messages MT 030 and MT 050

2.1 SWIFTNet FINCopy Service Parameters

Parameters
SWIFTNet FINCopy enables a service administrator to operate another service, for example Real-
Time Gross Settlement (RTGS), netting, or clearing. The service administrator must establish a
unique set of parameters for each implementation to govern the provision of the SWIFTNet
FINCopy service.
The service administrator defines these parameters on the Service Profile Form:

• message selection

• message validation

• additional parameters for the service

The message selection criteria for SWIFTNet FINCopy are as follows:

• the SWIFTNet FINCopy Service Identifier code, which is a three-character code used in field
103 of the user header

• the message types that SWIFTNet FINCopy must copy

• other message types that can be exchanged by users that participate in the SWIFTNet FINCopy
CUG

• the participation of the sender and receiver in the SWIFTNet FINCopy CUG. See "Closed User
Groups" on page 31.
The message validation criteria is as follows:

• the currency code (optional)

• the authentication mode. See "Double Authentication" on page 31 for a description of the
SWIFTNet FINCopy Service double authentication mechanism.

• the usage definition - live or Test and Training (T&T) service

16 February 2007 15
SWIFTNet FINCopy

The service administrator can define the following additional parameters:

• Full or partial copying of the message.

• The identification of the service administrator's live or T&T destination that will be used for
Bilateral Key Exchange (BKE), until the migration to SWIFTNet Phase 2 is completed. During
and after the migration to SWIFTNet Phase 2, all SWIFTNet PKI signing operations will use a
certificate associated with the service administrator's live destination.

• The service mode profile - Y-Copy or T-Copy.

• The fallback service mode - Bypass or T-Copy mode, or closed-service state.

• Optional sender notification in Y-Copy mode. See: "Optional Sender Notification" on

page 20.

• Whether certain messages that the service administrator sends to the users that participate in
the SWIFTNet FINCopy CUG are billed to the user or the service administrator. If SWIFT bills
the users that participate in the SWIFTNet FINCopy CUG, then this is known as reverse billing.
Before starting SWIFTNet FINCopy operations, the service administrator must determine, in
agreement with SWIFT, the parameters for that service. SWIFT provides support for the definition
of these parameters.
From the parameters that the service administrator provides, SWIFT creates two SWIFTNet
FINCopy Services: one for live operation and one for T&T purposes.

Note SWIFTNet FINCopy Services can use different parameters for live operation and
T&T.
Before starting the operations, all SWIFTNet FINCopy parties (that is, the service
administrator and the users that participate in the SWIFTNet FINCopy CUG) must
include the SWIFTNet FINCopy service parameters in the SWIFTNet FIN interface
for both the live and the T&T services.

For a sample SWIFTNet FINCopy service profile, see Appendix A, "SWIFTNet FINCopy Service
Profile" on page 57.

2.2 SWIFTNet FINCopy Service Modes

Introduction
The SWIFTNet FINCopy service can operate in the following modes:

• Y-Copy

• T-Copy

• Bypass
In normal operations, SWIFTNet FINCopy operates in either Y-Copy or T-Copy mode. SWIFT
reserves Bypass mode for specific, abnormal situations.
In Y-Copy mode, SWIFTNet FINCopy copies messages to the service administrator, and stores
these messages until it receives authorisation or refusal from the service administrator.
In T-Copy mode, SWIFTNet FINCopy copies messages to the service administrator and
immediately forwards the messages for delivery to the receiver.
In Bypass mode, SWIFTNet FINCopy does not copy the messages to the service administrator.

16 Service Description
 Features and Functions

Modes and Actions

Mode Message selected Message copied? Wait for

for SWIFTNet authorisation?
FINCopy
processing?

Y-Copy yes yes yes

T-Copy yes yes no

Bypass yes no no

2.2.1 Y-Copy Mode

Message flow
In Y-Copy mode, the message flow is as follows:

1. A user that participates in a SWIFTNet FINCopy CUG sends a user-to-user message, for
example MT 103, to a receiver. To identify this message as a SWIFTNet FINCopy user-to-
user message, the sender adds field 103 to block 3, the user header. This field contains the
service code of the requested SWIFTNet FINCopy service. The service definition within
SWIFTNet FIN determines whether the message is Y-Copy or T-Copy.

2. SWIFTNet FINCopy intercepts the user-to-user message and copies some or all fields into
an MT 096 to the service administrator. MT 096 is equivalent to a request to execute the
transaction. SWIFTNet FINCopy holds the original user-to-user message until it receives the
appropriate instruction from the service administrator.

3. The service administrator's decision to authorise the user-to-user message is based on the
MT 096 information and other data, for example, the sender's balance. The service
administrator may delay the authorisation if the system allows payments to be queued until
balances are sufficient to enable processing.

4. The service administrator returns a delivery authorisation or refusal to the SWIFTNet FINCopy
service in the form of a SWIFTNet FINCopy Message Authorisation/Refusal Notification MT
097.

5. Based on the information in MT 097, SWIFTNet FINCopy either delivers the user-to-user
message, or aborts it and sends an Abort Notification MT 019 to the sender.
See also: "Figure 3: Y-Copy message flow: sender phase", "Figure 4: Y-Copy message flow:
service administrator phase: authorised message" and "Figure 5: Y-Copy message flow:
service administrator phase: rejected message".

16 February 2007 17
SWIFTNet FINCopy

Figure 3: Y-Copy message flow: sender phase

MT 103
Sender Receiver

MT 096

Temporary queue
MT 103 awaiting
response from
Service Administrator

D0110003
Service Administrator

Figure 4: Y-Copy message flow: service administrator phase: authorised message

MT 103 MT 103
Sender Receiver

MT 096

MT 103 authorised
MT 097 by Service Administrator
and transmitted
to receiver

D0110004

Service Administrator

18 Service Description
 Features and Functions

Figure 5: Y-Copy message flow: service administrator phase: rejected message

MT 019

Sender MT 103 Receiver

✗
MT 096

MT 103 rejected by
MT 097 Service Administrator
with MT 019 Abort
Notification to sender

D0110005
Service Administrator

2.2.1.1 Monitoring Messages

Available message types

The following monitoring capabilities are also available:

• As part of the normal SWIFTNet FIN Service, the sender can request that SWIFTNet FIN
monitors the delivery of sent messages. In this case, SWIFTNet FIN returns a Delivery
Notification MT 011 and, or a Nondelivery Warning MT 010 to the sender, as appropriate. These
notifications are based on the delivery of the original message to its receiver, and not on the
delivery of the copy to the service administrator.

• To examine the SWIFTNet FINCopy hold queue, the service administrator can send a
SWIFTNet FINCopy Message Status Request MT 028. SWIFTNet FINCopy responds with a
SWIFTNet FINCopy Message Status Report MT 029.

• The service administrator can also send a Cut-off Time Reconciliation Request MT 030 to
SWIFTNet FIN. SWIFTNet FIN responds with Cut-off Time Reconciliation Report MT 050. This
report states the number of undelivered messages to the service administrator at the specified
time.
See: "Figure 6: Monitoring messages: authorised transaction: optional messages".

16 February 2007 19
SWIFTNet FINCopy

Figure 6: Monitoring messages: authorised transaction: optional messages

Optional Delivery Notification

MT 011/MT010

Sender MT 103 MT 103 Receiver

MT 096 MT 097

Y-Copy mode
authorised
transaction

SWIFTNet FINCopy MT 028 MT 030 Cut Off Time

Message Status Reconciliation Request

D0110006
Request and MT 029 MT 050 and Report
Report Service Administrator

Note For more information about the SWIFTNet FIN system and service messages, see
the SWIFTNet FIN System Messages.

2.2.1.2 Optional Sender Notification

Use of MT012
An optional feature of Y-Copy mode is MT 012 for Sender Notification. This feature, which the
service administrator selects during the implementation phase, conveys information to the sender
of the original user-to-user message. The service administrator inserts field 114<payment-
release-information-sender> into the MT 097 SWIFTNet FINCopy Message
Authorisation/Refusal Notification. SWIFTNet FINCopy then transmits an MT 012 Sender
Notification to the sender of the original message identified in field 114.

Note The service administrator can only use MT 012 Sender Notification when MT 097 is
an authorisation message. SWIFTNet FINCopy does not generate MT 012 when MT
097 is a rejection message, even if MT 097 contains field 114.

For more information about this optional feature, see "Relationship between SWIFTNet FINCopy
and SWIFTNet FIN" on page 47.
The modified message flow using Sender Notification is illustrated in "Figure 7: Y-Copy message
flow with sender notification".

20 Service Description
 Features and Functions

Figure 7: Y-Copy message flow with sender notification

MT 012

Sender MT 103 MT 103 Receiver

MT 096 MT 097

MT 103 authorised
by Service Administrator
and transmitted to
receiver with optional
MT 012 Sender
Notification

D0110007
Service Administrator

Note The service administrator decides whether to offer this feature for the service. It can
be applied to all or some messages, based on MT, amount, or other criteria.

2.2.1.3 Optional Receiver Notification

Use of Field 115

Another optional feature of Y-Copy is Receiver Notification. It only applies to authorised messages.
This feature, which is always available to the service administrator, conveys information to the
intended receiver of the authorised user-to-user message.
The service administrator inserts field 115 <payment-release-information-receiver> in
the MT 097 SWIFTNet FINCopy Message Authorisation/Refusal Notification. If the MT 097 is an
Authorisation Notification, SWIFTNet FINCopy adds the field and its contents to the user header
block of the user-to-user message, then forwards the message to the receiver.

2.2.2 T-Copy Mode

Message flow
As with Y-Copy, the service administrator determines the range of messages available in T-Copy
mode for the users that participate in the SWIFTNet FINCopy CUG. The message flow, shown in
"Figure 8: T-Copy message flow", is as follows:

• The sender transmits a user-to-user message, for example, an MT 103, to a receiver. To identify
this message as a SWIFTNet FINCopy user-to-user message, the sender adds field 103 to
block 3, the user header. This field contains the identification of the requested SWIFTNet
FINCopy service. The service definition within SWIFTNet FIN determines whether the message
is Y-Copy or T-Copy.

• SWIFTNet FINCopy intercepts the user-to-user message, and copies some or all of its fields
into an MT 096 to the service administrator . Unlike Y-Copy mode, SWIFTNet FINCopy does
not hold the user-to-user message for service administrator approval. The message is treated
as a normal SWIFTNet FIN message, and is forwarded directly to the receiver.

• The service administrator uses the information copied in the MT 096 for whatever service it
provides. If that service involves an information flow between the service administrator and

16 February 2007 21
SWIFTNet FINCopy

either the sender or receiver, the service administrator advises the sender and/or receiver of
the message status outside of the SWIFTNet FINCopy message dialogue, as there is no MT
097 SWIFTNet FINCopy Message Authorisation/Refusal Notification.

Figure 8: T-Copy message flow

MT 103

Sender Receiver
MT 096

Optional advice from

Service Administrator
to sender and/or receiver,
outside scope of SWIFTNet
T -Copy
mode
FINCopy, but may use
SWIFTNet FIN messaging

D0110008
Service Administrator

2.2.3 Bypass Mode

Emergency mode
The service administrator can ask SWIFT to operate an active Y-Copy service in Bypass mode.
This emergency mode is only appropriate in disaster situations, not during normal operations.
Bypass mode operates as follows:

• The sender transmits a user-to-user message, for example, an MT 103 to a receiver. To identify
this message as a SWIFTNet FINCopy user-to-user message, the sender adds field 103 to
block 3, the user header. This field contains the identification of the requested SWIFTNet
FINCopy service. The service definition within SWIFTNet FIN determines whether the message
is Y-Copy or T-Copy.

• SWIFTNet FINCopy intercepts the user-to-user message, but cannot copy anything to the
service administrator. SWIFTNet FINCopy treats the user-to-user message as a normal
SWIFTNet FIN message, and forwards it directly to the receiver. See "SWIFTNet FINCopy
Service Fallback" on page 50.

Note When the service is in emergency Bypass mode, the service administrator must
advise users that participate in the SWIFTNet FINCopy CUG that messages are not
copied.

2.3 Service States

Open and closed states
A SWIFTNet FINCopy Service operating in one of the three modes: Y-Copy , T-Copy , or Bypass,
is in either an open or closed state.
During normal operations, the service state is open.

22 Service Description
 Features and Functions

SWIFT can only change service modes if the service state is closed. If a service administrator asks
SWIFT to operate its declared fallback mode in an emergency, SWIFT closes the state, changes
the mode, then reopens the service.
In the absence of problems, the implementation time for emergency changes to SWIFTNet
FINCopy parameters (change of mode, withdrawal of a user) is 45 minutes. This period starts from
the time that the SWIFT Customer Service Centre (CSC) has authenticated the service
administrator, and has received a confirmation fax from the service administrator.
In some circumstances, fallback may only require SWIFT to close the service state.

Note A message requesting a SWIFTNet FINCopy service when the service is closed
receives a Negative AcKowledgement (NAK), with an appropriate error code. For
explanations of SWIFTNet FIN Error Codes, see the SWIFTNet FIN Error Codes.

2.4 Service Messages

How SWIFTNet FINCopy monitors message traffic
The SWIFTNet FIN system monitors message traffic between users that participate in a SWIFTNet
FINCopy CUG and selects the messages that fulfil the following requirements:

• The message contains a valid SWIFTNet FINCopy Service Identifier Code.

• The message type is defined in the SWIFTNet FINCopy service parameters.

• The sender and the receiver both participate in the SWIFTNet FINCopy CUG.

• The message passes standard input validation.

• The message passes specific but optional SWIFTNet FINCopy validation that is based on
currency code or dual authentication, or both.

• The message passes service specific validation.

From each message that SWIFTNet FINCopy selects, certain information is copied into the
envelope MT 096 SWIFTNet FIN Copy Service to Service Administrator message. In Y-Copy, the
service administrator's response is the MT 097 SWIFTNet FINCopy Message Authorisation/
Refusal Notification.

2.4.1 MT 096 SWIFTNet FIN Copy Service to Service

Administrator Message
Message from system to the service administrator
SWIFTNet FINCopy sends an MT 096 to the service administrator. SWIFTNet FINCopy generates
this message when a user that participates in a SWIFTNet FINCopy CUG places the appropriate
SWIFTNet FINCopy service identification code in the user header field 103 of a user-to-user
message that is addressed to a user that participates in the same SWIFTNet FINCopy CUG. This
service code instructs SWIFTNet FINCopy to copy the message, according to the definition of the
specified SWIFTNet FINCopy service.
As shown in "Figure 9: MT 096 structure", the MT 096, SWIFTNet FIN Copy Service to Service
Administrator Message, is a system-to-user message that envelopes information from the original
user-to-user message. The text block of the MT 096 contains all the blocks of the original message
(that is, basic header, application header, user header, text, and trailer blocks), including a

16 February 2007 23
SWIFTNet FINCopy

dedicated user Message Reference (MRF) trailer that SWIFTNet FINCopy inserts to specify the
message reference of the original user-to-user message. The format of this trailer is as follows:
<yymmdd><hhmmss><mir>
where<yymmdd><hhmmss> represents the input message acceptance date and time (GMT) and
<mir> is the 28-character original user-to-user message input reference.
The specific SWIFTNet FINCopy Service Profile determines which fields of the original message
text block are copied.

Figure 9: MT 096 structure

MT 096 SWIFTNet FIN Copy Service to Service Administrator Message

Basic header
Application header
User header

Text block
" Basic header
Application header
User header
Text (some or all fields)
Trailer block "

Trailer block

Envelope Copy of original message

D0110009

The MRF is specific to SWIFTNet FINCopy. The sole purpose of the MRF is to enable SWIFTNet
FINCopy to identify the MT 096 to which the MT 097 is a response. The MRF is an automatically
generated trailer in the MT 096 and can only be reused in field 109 of the MT 097. The format of
the MRF may change without prior notice.
If the institution that sent the original message is a synonym, its master BIC8 appears in the MRF.

Main Use
The MT 096 is a SWIFTNet FIN system message from SWIFTNet FINCopy to the service
administrator. See the SWIFTNet FIN System Messages for details of the MT 096 header and
trailer blocks. For MT 096 examples, see Appendix B, "Case Studies for SWIFTNet Phase 1" on
page 63 and Appendix C, "Case Studies for SWIFTNet Phase 2" on page 81.
The following table describes the block format of the MT 096.

Table 2 - MT 096 format

Block Content or comment

1,2, and 3 Standard header blocks for a SWIFTNet FIN system message.
SWIFTNet FINCopy puts the SWIFTNet FINCopy Service Identifier

24 Service Description
 Features and Functions

Block Content or comment

Code that it has copied from the original user-to-user message, into
Field 103 in Block 3.

4 Text block, containing the header blocks, some or all of the text
fields, and the trailer block of the original user-to-user message.

5 Standard trailer block for a SWIFTNet FIN system message.

2.4.2 MT 097 SWIFTNet FINCopy Message Authorisation/

Refusal Notification
Message from service administrator to system
In Y-Copy, the service administrator sends the MT 097 to SWIFTNet FINCopy. Each MT 097 is a
response to an MT 096 from SWIFTNet FINCopy.
The decision to allow or refuse delivery of the original user-to-user message is based on:

• information in the MT 096

• any additional available information the service administrator has about the sender and receiver
The service administrator uses the MT 097 SWIFTNet FINCopy Message Authorisation/Refusal
Notification to convey the decision to authorise or refuse the original user-to-user message to
SWIFTNet FINCopy.
As shown in "Figure 10: MT 097 structure", the text block of the MT 097 contains the following:

• the original SWIFTNet FINCopy Service Identifier Code

• the MRF trailer from the MT 096

• an indication of authorisation or rejection

When a message is rejected, the service administrator must add a code in field 432
<abortreason> of the MT 097 that indicates the reason for the abort.
Optionally, in authorised messages, the text block of the MT 097 also contains the following:

• information for the sender (in field 114). This information is returned to the sender in an MT 012.

• information for the receiver (in field 115). This information is added to the authorised user-to-
user message when it is sent to the receiver.

16 February 2007 25
SWIFTNet FINCopy

Figure 10: MT 097 structure

MT 097 SWIFTNet FINCopy Message Authorisation/

Refusal Notification

Basic header
Application header
User header

Text block
" FINCopy service identifier code
MRF trailer from MT 096
Acceptance/rejection code

Abort reason

Information for sender

Information for receiver "

Trailer block

Envelope Optional Mandatory if code is 'Reject' Mandatory

D0110010
contents otherwise, not present contents

The MT 097 is a SWIFTNet FIN system message from the service administrator to SWIFTNet
FINCopy. This message applies to the SWIFTNet FINCopy service only. For details of the MT 097
header and trailer blocks, see the SWIFTNet FIN System Messages. For examples of the MT 097,
see Appendix B, "Case Studies for SWIFTNet Phase 1" on page 63 and Appendix C, "Case
Studies for SWIFTNet Phase 2" on page 81.

Note For each MT 096 received from SWIFTNet FINCopy in Y-Copy mode, a service
administrator must send a response to SWIFTNet FINCopy using the MT 097. The
MT 097 can be sent at a later time but must be sent from the server destination that
received the MT 096.

The following table shows the text block format of the MT 097.

Contents of the MT 097 text block

MT 097 format

Tag Field Content or comments

103 service-code SWIFTNet FINCopy service Identifier code.

109 original-user-message-reference Contents of the MRF trailer present in the corresponding

MT 096.

451 accept-reject 0 = Accepted

1 = Rejected

432 abort-reason Message rejection code: SWIFTNet FINCopy service-

specific within the range 50-ZZ.
(If Field 451 contains an acceptance code, service
administrators must not use this field. If Field 451
contains a rejection code, this field must be present.)

26 Service Description
 Features and Functions

Tag Field Content or comments

114 payment-release-information-sender Information from service administrator to sender of

payment message. (The presence of tag 114 generates
an MT 012 to the sender of the original message. The
contents of tag 114 are copied into the MT 012)
(The contents of this field are ignored if Field 451
contains a rejection code.)

115 payment-release-information-receiver Information from service administrator to receiver of

payment message. This is added to the original
message when it is output.
(The contents of this field are ignored if Field 451
contains a rejection code.)

2.4.3 MT 028 SWIFTNet FINCopy Message Status Request

Service administrator: information request
A service administrator uses the MT 028 SWIFTNet FINCopy Message Status Request to request
information about messages awaiting authorisation.

MT 028 text block format

Tag Field Content or comments

103 service-code SWIFTNet FINCopy Service Identifier Code.

243 hold-queue-request-type Type of hold queue report, where:

1 = Counts and MIRs
2 = Counts only

177 date-time Start time local to the SWIFTNet FINCopy service

administrator.

177 date-time Cut-off or end time local to the SWIFTNet FINCopy

service administrator.

This message always requires the first two fields. The service administrator must specify the
SWIFTNet FINCopy Service Identifier code and the type of report it requires, as follows:

• 1 = the number of messages in the queue and the MIR for each message

• 2 = only the number of messages in the queue

The remaining two fields 177 define the time period of the report, as follows:

• if these fields are absent, then SWIFTNet FINCopy assumes that the current date and time
represent the cut-off for the report

• if only one field 177 is present, then SWIFTNet FINCopy assumes that it states the cut-off time

• if both fields are present, then SWIFTNet FINCopy assumes that the first field is the start time
and the second field is the cut-off time
All times are local to the service administrator.
See the SWIFTNet FIN System Messages for more details.

16 February 2007 27
SWIFTNet FINCopy

2.4.4 MT 029 SWIFTNet FINCopy Message Status Report

Response to service administrator
In response to a service administrator's MT 028 SWIFTNet FINCopy Message Status Request,
SWIFTNet FINCopy generates an MT 029 SWIFTNet FINCopy Message Status Report. The
report contains the information that the service administrator has requested.

MT 029 text block format

Tag Field Content or Comments

202 section-number Number of the section in a multi-

section message, starting with
"0001".

203 total-sections Total number of sections in a multi-

section message.

177 date-time Start time local to the SWIFTNet

FINCopy service administrator.

177 date-time Cut-off or end time local to the

SWIFTNet FINCopy server.

103 service-code SWIFTNet FINCopy Service

Identifier code.

343 cut-off-time-count See explanation.

106 MIR Message Input Reference. The

SWIFTNet FINCopy report can
contain up to 40 MIRs, describing
the messages that SWIFTNet
FINCopy has on hold for that
service.

Fields 202 and 203 are always present in the report. The two fields 177 are present in the first
section of the report, if present in the original MT 028 request. The final part of the report contains
the SWIFTNet FINCopy Service Identifier Code and a combination of the final two fields in the
preceding table. The last two fields depend on the type of request in the MT 028.
Field 343, <cut-off-time-count>, shows the number of urgent and normal user-to-user
messages queued in SWIFTNet FINCopy, within the date-time range specified in the MT 028.
SWIFTNet FINCopy holds the messages because:

• The sender marked them as copy messages in a Y-Copy service, so SWIFTNet FINCopy copied
them to the service administrator and placed them in a hold queue.

• SWIFTNet FINCopy hasn't had an MT 097 back from the service administrator.

2.4.5 MT 030 Cut-off Time Reconciliation Request

Cut-off time reconciliation request
Customers use the MT 030 SWIFTNet FIN system message to reconcile messages queued for
delivery in relation to the receiver's cut-off time. To use this message, the delivery subsets of the
receiver's destination must be configured for value-date-sensitive queuing.

28 Service Description
 Features and Functions

2.4.6 MT 050 Cut-off Time Reconciliation Report

Cut-off time monitoring response
SWIFTNet FIN sends the MT 050 message in response to the MT 030 Cut-off Time Reconciliation
Request. It lists the number of messages by delivery subset, according to the specifications in the
request.

Note For more information about the MT 030 and MT 050, see the SWIFTNet FIN System
Messages.

16 February 2007 29
SWIFTNet FINCopy

30 Service Description
 Security and Control

3 Security and Control

Introduction
This chapter describes the use within SWIFTNet FINCopy of aspects of the SWIFTNet FIN
messaging service that SWIFT has designed to enhance its integrity and security. It covers the
following topics:

• Closed User Groups (CUGs)

• double authentication

3.1 Closed User Groups

SWIFTNet FINCopy CUGs
SWIFT implements SWIFTNet FINCopy on the basis of CUGs. The service administrator defines
the types of messages which users that participate in the CUG can use within that SWIFTNet
FINCopy service. CUG characteristics form part of the SWIFTNet FINCopy service parameters.
Users that participate in the CUG communicate within the CUG for certain types of messages or
services. Communication for these messages or services is not possible with correspondents that
do not participate in the CUG. For example, the users that participate in a SWIFTNet FINCopy
CUG can exchange SWIFTNet FINCopy messages only with each other. As possible participants
of the larger SWIFTNet FIN user group, they can exchange messages not related to SWIFTNet
FINCopy with all other participants of that group, within the confines of the normal SWIFTNet FIN
message routing restrictions.
Changes to users that participate in a CUG take effect following an Allowable Downtime Window
(ADW), provided that Customer Ordering Services (COS) has received the correct update
information from the service administrator at least 14 days before the required update time.
All SWIFTNet FINCopy services use the same copy mechanism within SWIFTNet FIN. However,
each SWIFTNet FINCopy service is defined individually.

3.2 Double Authentication

Sender of original message
The SWIFTNet FIN Service enables its users to verify the origin and the integrity of the message
texts by means of authentication.
In SWIFTNet Phase 1, SWIFTNet FIN messages use an authentication mechanism based on
Bilateral Key Exchange (BKE) between the sender and the receiver. The exchanged key is used
to generate a message authenticator called the Message Authentication Code (MAC). The MAC
is carried in the MAC trailer of an authenticated message. The migration to SWIFTNet Phase 2
will replace the MAC and the MAC trailer with a SWIFTNet PKI-based digital signature.
SWIFTNet FINCopy supports an optional double authentication mechanism. To do this, it uses a
Proprietary Authentication Code (PAC). The PAC is carried in the PAC trailer of a double
authenticated message. The PAC allows the service administrator to verify the origin and integrity
of the copied data. The PAC also allows the recipient of a user-to-user Y-Copy message to verify
the identity of the service administrator which has authorised the message. In SWIFTNet phase
1, the service administrator and the users that participate in the CUG use BKE to exchange keys.
These keys are used to generate the PAC. The migration to SWIFTNet Phase 2 will replace the
PAC with SWIFTNet PKI-based digital signatures.

16 February 2007 31
SWIFTNet FINCopy

Double authentication
In support of message authentication and integrity, if the service administrator has specified the
use of double authentication in the service profile, then SWIFT enforces its use between the sender
and the service administrator (for T-copy and Y-copy), and between the service administrator and
the receiver (for Y-copy).
For more information about message authentication, see "Authentication Mode" on page 58.

Note Whereas message authentication only applies to certain messages, double

authentication may apply to any SWIFTNet FINCopy message. This means a
message may contain a PAC trailer or its PKI equivalent without a MAC trailer or its
PKI equivalent.

SWIFT BIC8 address

The service profile contains the service administrator destination formerly known as the Central
Institution Destination (CID). Users that participate in the SWIFTNet FINCopy CUG must use this
address for Bilateral Key Exchange (BKE) with the service administrator. In SWIFTNet phase 2,
a SWIFTNet PKI certificate associated with the CID will be used for double authentication of
SWIFTNet FINCopy messages. When operating in test and training mode, a certificate associated
with the live CID destination must be used for all signing operations.
For Y-Copy, there may be two or three authentication results as shown in "Figure 11: Double
authentication mechanism".
When the authentication parameters are added to the SWIFTNet FIN Interface configuration, the
double authentication process is automatic.

Central institution
If double authentication is defined for the SWIFTNet FINCopy service, the service administrator
must calculate a second PAC or its PKI equivalent, or both, when generating the MT 097
SWIFTNet FINCopy Message Authorisation/Refusal Notification. The user-to-user message that
SWIFTNet FIN forwards to the receiver contains the authentication elements calculated by the
sender and by the service administrator.
The symmetric authentication techniques that SWIFT uses to calculate MAC and PAC mean that
users that participate in a SWIFTNet FINCopy CUG must perform BKE, as follows:

• If the SWIFTNet FINCopy Service Profile specifies that users that participate in that SWIFTNet
FINCopy CUG can exchange authenticated SWIFTNet FIN messages with other users that
participate in that CUG, then all users that participate in that CUG must perform BKE with all
correspondents in the CUG.

• If the SWIFTNet FINCopy Service Profile specifies that users that participate in that SWIFTNet
FINCopy CUG must apply double authentication to SWIFTNet FINCopy messages, then the
service administrator must perform BKE with all users that participate in the CUG. This key
exchange is the responsibility of the service administrator.

32 Service Description
 Security and Control

Figure 11: Double authentication mechanism

MAC or PKI equivalent

Sender Receiver

First PAC, Second PAC

PKI equivalent, or
or both PKI equivalent,
(T-Copy and (Y-copy
Y-Copy modes) mode only)

D0110011
Service Administrator

Double authentication results in the following:

• During the migration to SWIFTNet Phase 2, the sender generates a Proprietary Authentication
Code (PAC), a SWIFTNet PKI equivalent, or both. SWIFTNet FINCopy copies any PAC and,
or digital signature in the message when it queues the copy message to the service
administrator. The receiver of the original message will receive either a MAC or a digital
signature from the sender.

• In Y-Copy mode, the service administrator generates a second PAC, a SWIFTNet PKI
equivalent, or both. This second PAC is based on the bilateral key exchanged with the receiver.
SWIFTNet FINCopy includes any second PAC and, or digital signature when it queues the
message to the receiver. SWIFTNet FIN does not include the first PAC when it queues the
message to the receiver. Depending on the migration status of the receiver, only the second
PAC or its PKI equivalent will be delivered.
In T-Copy there is no second PAC or signature, even when double authentication is specified, as
there is no service administrator-to-receiver message involved.

Bypass mode
When SWIFTNet FINCopy service is in Bypass mode and the CUG service profile specifies double
authentication, SWIFTNet FINCopy appends an empty second PAC trailer to the message queued
to the receiver. This will continue to be the case after the migration to SWIFTNet Phase 2. This
indicates to the receiver that the message has not been authorised by the service administrator.
For an example of an empty PAC trailer, see "Figure 25: MT 103 as delivered to Receiverbank".

16 February 2007 33
SWIFTNet FINCopy

34 Service Description
 Service Administrator Responsibilities

4 Service Administrator Responsibilities

Introduction
This chapter describes the SWIFTNet FINCopy procedures that the service administrator must
perform. It covers the following topics:

• creation of the contractual relationship with SWIFT for SWIFTNet FINCopy

• definition of the SWIFTNet FINCopy Service Profile

• communication with users that participate in the SWIFTNet FINCopy Closed User Group (CUG)

• day-to-day operations

• administration of the SWIFTNet FINCopy CUG

• other service administration responsibilities

Further details
Appendix D, "Service Administrators Operations Guide" on page 99 contains a detailed
description of administrative and technical procedures that the service administrator and SWIFT
perform. These procedures form the implementation and operation of a SWIFTNet FINCopy
Service.

4.1 Implementation
4.1.1 Procedure
4.1.1.1 Service Administrator Agreement and Project Plan

Actions to take
Before a SWIFTNet FINCopy service can be set up, the service administrator and SWIFT must
sign a Service Administration Agreement (SAA). Without an SAA, a service administrator cannot
have permission from the SWIFT Board to set up the SWIFTNet FINCopy service. The service
administrator uses the Service Approval Request Form (SARF) to obtain this permission.

4.1.1.2 Service Profile

Operational parameters
When the implementation timetable is established, the service administrator must define the
parameters to govern the operation of the SWIFTNet FINCopy service. This comprises the
SWIFTNet FINCopy service profile for the live and T&T services. In particular, the service
administrator must do the following:

• Agree a SWIFTNet FINCopy Service Identifier Code with SWIFT, to be uniquely used for the
new service. Users that participate in this SWIFTNet FINCopy CUG place this code in the
header field 103 to indicate the messages for SWIFTNet FINCopy to copy. It can be any three
alpha characters, except where this can lead to confusion. The first two characters must be
unique, that is, no other financial community can use the same first two characters as a
SWIFTNet FINCopy Service Identifier Code. The third character must not be the letter X.

16 February 2007 35
SWIFTNet FINCopy

• Define the SWIFTNet FINCopy requirements, such as the service modes for live use and T&T,
and the service definition parameters which determine the rules to operate the service. These
parameters form the SWIFTNet FINCopy service profile. For more information about the service
profile parameters, see Appendix A, "SWIFTNet FINCopy Service Profile" on page 57.

• Agree the service administrator destination (CID) with SWIFT. The CID is used in Phase 1 for
BKE between the service administrator and the users that participate in the SWIFTNet FINCopy
CUG. In Phase 2 the CID is used to authenticate the service administrator authorisation/refusal
notification. See "Double Authentication" on page 31.

• Agree with SWIFT the other message types which users that participate in the SWIFTNet
FINCopy CUG can exchange.

• Agree with SWIFT two BIC8 addresses for the SWIFTNet FINCopy server destinations. SWIFT
requires two addresses for operational reasons. These destinations form part of the SWIFTNet
FINCopy service profile. SWIFTNet FINCopy and the service administrator use them for the MT
096 and MT 097 dialogue. The service administrator must send each MT 097 from the same
address as that which received the corresponding MT 096. Services with low traffic volumes
can operate with a single SWIFTNet FINCopy server destination when the service
administrator agrees this with SWIFT in advance.

Note Users that participate in the SWIFTNet FINCopy CUG do not normally see the
SWIFTNet FINCopy server destinations. Although these destinations are part of
the SWIFTNet FINCopy service profile, the service administrator does not have to
communicate them to the users that participate in the SWIFTNet FINCopy CUG.

• Define the numeric codes, range 50 to 99, and any alphanumeric codes for use as abort reason
codes in field 432 of MT 097 and MT 019. In the same manner, define any message status
codes for use in field 431 for nondelivery warnings, undelivered message reports, and retrieved
messages. See SWIFTNet FIN Error Codes.
The service administrator must also establish adequate lines of communication within the
SWIFTNet FINCopy CUG, and inform all users that participate in the CUG of the Service Profile
details. The service administrator also distributes to the group the details of all users that
participate in the SWIFTNet FINCopy CUG. Users that participate in the CUG need these details
for Bilateral Key Exchange (BKE) within the CUG.

Note When the service is in live operation, the service administrator must ensure that the
communication methods are adequate for routine and emergency situations. This
is to enable communication to some or all users that participate in the SWIFTNet
FINCopy CUG, for any day-to-day operational matters that affect both SWIFTNet
FINCopy and the underlying service.

References

SWIFTNet FINCopy service information

Topic Reference

Abort reason codes and message status "Relationship between SWIFTNet FINCopy
codes and SWIFTNet FIN" on page 47

The service profile and parameters Appendix A, "SWIFTNet FINCopy Service

Profile" on page 57

Operational procedures Appendix D, "Service Administrators

Operations Guide" on page 99

36 Service Description
 Service Administrator Responsibilities

4.1.1.3 Operations Guide

Overview
The service administrator must abide by the procedures in Appendix D, "Service Administrators
Operations Guide" on page 99, summarised in this chapter.

4.1.2 Additional SWIFTNet FINCopy Server Destinations

MT 096 traffic
For a SWIFTNet FINCopy Service with a large volume of SWIFTNet FINCopy messages, a service
administrator can request additional server destinations. This is in addition to the two prime server
destinations (see "Service Profile" on page 35). In this way, a service administrator can spread
the MT 096 and MT 097 traffic over multiple destinations. Alternatively, the service administrator
can define the server destination Logical Terminals (LTs) to share the delivery subset in which the
MT 096 is queued.
SWIFT and the service administrator must decide the most appropriate solution for each service.

SWIFTNet FINCopy user and server assignment

The service administrator can assign users that participate in a SWIFTNet FINCopy CUG to a
server, according to the traffic volume that the user expects. However, in the absence of specific
mapping information, the SWIFTNet FINCopy service uses the two prime server destinations.

Note Such server assignments must be acceptable to SWIFT within the context of network
load-sharing.

4.1.3 SWIFTNet FIN Interfaces

Suitability for SWIFTNet FINCopy
A service administrator, which is already a SWIFTNet FIN user and has a SWIFTNet FIN interface,
must confirm with the supplier that the interface supports SWIFTNet FINCopy. The SWIFTNet FIN
interface configuration must be modified to include the SWIFTNet FINCopy server destinations
that the service administrator defines. The service administrator must also ensure the SWIFTNet
FIN Interface has adequate connectivity to support the service needs.
Service administrators without a SWIFTNet FIN Interface must acquire one for each of the defined
SWIFTNet FINCopy server destinations. The interface must be able to send and receive the
SWIFTNet FINCopy Service messages and any other messages that are necessary to operate
the specified service.

4.2 Operational
Message exchange
For each user-to-user message sent between the users that participate in a SWIFTNet FINCopy
CUG, SWIFTNet FINCopy copies specific information from the user-to-user message into an MT
096 SWIFTNet FIN Copy Service to Service Administrator Message. SWIFTNet FINCopy sends
the MT 096 to the service administrator.
In Y-Copy mode, the service administrator must respond with an MT 097 SWIFTNet FINCopy
Message Authorisation/Refusal Notification for each MT 096 received. This applies for both live

16 February 2007 37
SWIFTNet FINCopy

and Test and Training (T&T) messages. In each MT 097, the service administrator must approve
or refuse the underlying transaction.

Note Service administrators must ensure that the MT 097 is sent from the same SWIFTNet
FINCopy server destination that received the MT 096.

Authentication
If double authentication has been defined in the SWIFTNet FINCopy service profile, the service
administrator must be able to calculate and check the Proprietary Authentication Code (PAC), its
SWIFTNet PKI equivalent, or both. The service administrator must also be able to calculate and
insert a PAC, a SWIFTNet PKI equivalent, or both, in the MT 097.
The service administrator's responsibilities for message authentication are given in the SWIFTNet
FIN Security Guide.
If the service administrator has defined that an MT 012 sender notification is required for the
SWIFTNet FINCopy service, the service administrator can add text in field 114 of the MT 097. The
service administrator can always place a text message for the receiver in field 115 of the MT 097 .
If the MT 097 contains a rejection code then:

• SWIFTNet FINCopy will not generate an MT 012, even if field 114 is present in the MT 097.

• SWIFTNet FINCopy aborts the original user-to-user message and notifies the sender.
SWIFTNet FINCopy does not notify the receiver and does not pass the contents of field 115 to
the receiver.

Additional service administrator message exchange

The service administrator's SWIFTNet FIN Interface can request SWIFTNet FINCopy message
status reports and cut-off time reconciliation reports from SWIFTNet FIN. To do this, the interface
sends an MT 028 SWIFTNet FINCopy Message Request, and an MT 030 Cut-off Time
Reconciliation Request. SWIFTNet FIN responds with an MT 029 SWIFTNet FINCopy Message
Status Report, and an MT 050 Cut-off Time Reconciliation Report.
The service administrator can also use the normal SWIFTNet FIN message retrieval functionality.
This includes the retrieval of MT 096 and MT 097 messages.

Note For full details of the system messages MT 028, MT 029, MT 030 and MT 050, see
SWIFTNet FIN System Messages.

The service administrator's operational responsibilities

The service administrator must ensure that its SWIFTNet FIN interface and other systems can
handle the predicted maximum traffic volume without causing undue delays to SWIFTNet FINCopy
messages queued in Y-Copy mode.
The service administrator must be able to send and receive the types of messages that are defined
in the service definition.
The service administrator must ensure that the system can handle the declared fallback procedure,
for example, operating in Bypass mode, followed by the return to Y-Copy mode. To initiate the
fallback procedure, the service administrator must contact the Customer Service Centre (CSC) to
request the closure, mode change and re-opening of the service. When the problem that caused
the fallback is solved, the service administrator must repeat the fallback procedure to revert to live.
For details of emergency procedures, including fallback procedures, see Appendix D, "Service
Administrators Operations Guide" on page 99.

38 Service Description
 Service Administrator Responsibilities

Valid SWIFTNet FINCopy service mode and state changes

Current Next service modes or states Reason for change

service available
mode

Y-Copy T-Copy, Bypass, Closed state fallback as specified in the SWIFTNet

FINCopy Service Profile

T-Copy Closed state fallback as specified in the SWIFTNet

FINCopy Service Profile

T-Copy Y-Copy recovery from fallback

Bypass T-Copy, Y-Copy recovery from fallback

Note Bypass mode is available only from services in Y-Copy mode.

Note For services operating in Test and Training (T&T) mode, the service administrator
must accommodate and manage the choice of mode (current or future) for the users
that participate in the SWIFTNet FINCopy CUG.
The MT 096, being a system message, is not dependent upon current or future
modes. It contains SWIFTNet FINCopy information appropriate to the mode that the
sender of the original T&T user-to-user message selected. In T&T, a service
administrator can receive MT 096s from users that participate in the SWIFTNet
FINCopy CUG that contain either the current or future version of the same user-to-
user message. SWIFT recommends that the service administrator declares the mode
for the T&T session to the users that participate in the CUG, and manages it manually.

4.3 General Responsibilities

Service administrator
In addition to the implementation procedures outlined in "Procedure" on page 35 and the
operational responsibilities in "Operational" on page 37, a service administrator must do the
following:

1. Be responsible for:

– informing SWIFT of the rules that govern access to, provision of, and use of this service

– determining the participation in the SWIFTNet FINCopy Closed User Group (CUG)

– the general administration of the CUG

– the provision of the service for users that participate in the CUG

2. Serve as the primary SWIFT contact for the provision of the SWIFTNet FINCopy service. The
service administrator must, without limitation, assist SWIFT to distribute relevant forms and
documents to prospective or participating users of SWIFTNet FINCopy. The service
administrator must also assist SWIFT with the subscription to and provision of the SWIFTNet
FINCopy service and related SWIFT services and products.

3. Assist SWIFT in the prompt and accurate completion and application, as appropriate, of forms
and other documents. Forward approved SWIFTNet FINCopy user subscription forms
promptly to SWIFT.

16 February 2007 39
SWIFTNet FINCopy

4. Define the initial service parameters for the provision of the SWIFTNet FINCopy service
without delay and in cooperation and agreement with SWIFT. Define any subsequent
amendments to the relevant service profiles.

5. Make sure that the initial service profile for the SWIFTNet FINCopy service is completed and
returned promptly to SWIFT. Make sure any subsequent amendments are also forwarded
promptly to SWIFT.

6. Ensure that all participants understand and implement the initial service profile and any
subsequent amendments promptly.

7. Have the necessary capacity and authority to perform the obligations of service
administrator. These obligations include, without limitation, the authority to allow, refuse, or
withdraw SWIFTNet FINCopy users in, or from, the SWIFTNet FINCopy CUGs.

Related procedures
For more information about the related procedures, see Appendix D, "Service Administrators
Operations Guide", and "Procedures".
The service administrator must be able to communicate with SWIFT by means of the MT 999 at
all times.

40 Service Description
 SWIFTNet FINCopy User's Responsibilities

5 SWIFTNet FINCopy User's Responsibilities

Introduction
This chapter describes the SWIFTNet FINCopy procedures which users that participate in a
SWIFTNet FINCopy CUG must perform. It covers the following topics:

• implementation procedures

• technical requirements

• day-to-day operations

5.1 Implementation
5.1.1 Procedures
Startup procedures
To participate in a SWIFTNet FINCopy service, customers must do the following:
1. The applicant SWIFTNet FINCopy user must be a duly registered SWIFT user, entitled under
the SWIFT by-laws to send and receive the messages in the relevant SWIFTNet FINCopy
service. The applicant must then apply to enter the SWIFTNet FINCopy Closed User Group
(CUG) for that SWIFTNet FINCopy service. The applicant must subscribe via SWIFT's e-
ordering tool that is available on www.swift.com > Ordering & Support. The service
administrator will authorise online.

2. If the SWIFTNet FINCopy service profile specifies authenticated message types, then the
user that participates in the SWIFTNet FINCopy CUG must ensure that it exchanges
authentication keys with all other users that it may want to exchange messages with, which
participate in that SWIFTNet FINCopy CUG. In addition, if the service profile specifies double
authentication, then the user that participates in the SWIFTNet FINCopy CUG must also
exchange authentication keys with the service administrator. The address for Bilateral Key
Exchange (BKE) with the service administrator is the service administrator destination (CID),
which is listed in the Service Profile for the relevant SWIFTNet FINCopy service. It is also the
SWIFTNet PKI certificate associated with the CID destination which will be used to generate
the digital signatures required in the case of double authentication. The BKE procedure is
documented in the SWIFTNet FIN Security Guide.

5.1.2 SWIFTNet FIN Interface

Requirements
The user that participates in a SWIFTNet FINCopy CUG must have a SWIFTNet FIN Interface
that can send and receive SWIFTNet FIN message traffic. Users that participate in a SWIFTNet
FINCopy CUG must confirm with the interface supplier that their SWIFTNet FIN interface supports
SWIFTNet FINCopy.
To send and receive SWIFTNet FINCopy messages, the SWIFTNet FIN Interface of a user that
participates in a SWIFTNet FINCopy CUG must also be able to do the following:

• accept the use of Field 103 (the SWIFTNet FINCopy service Identifier Code) in the user header
of any message type that the SWIFTNet FINCopy service profile specifies as a SWIFTNet
FINCopy user-to-user message

16 February 2007 41
SWIFTNet FINCopy

• receive messages that the service administrator has authorised, and for which the service
administrator may have supplied information in Field 115

• add a Proprietary Authentication Code (PAC) trailer or the SWIFTNet PKI based digital
signature, or both, if the service administrator has specified double authentication in the
SWIFTNet FINCopy service profile

• receive and process a PAC trailer or its SWIFTNet PKI equivalent, or both, on an incoming
message, if the service administrator has specified double authentication in the SWIFTNet
FINCopy service profile

• receive and process a message with an empty PAC trailer, if the service administrator has
specified double authentication in the SWIFTNet FINCopy service profile, and the SWIFTNet
FINCopy service is in Bypass mode

Note All SWIFTNet FIN users that join a SWIFTNet FINCopy CUG receive, from the service
administrator (not from SWIFT), the SWIFTNet FINCopy service profile for the
specific SWIFTNet FINCopy service. This enables the user that participates in the
SWIFTNet FINCopy CUG to configure the SWIFTNet FIN interfaces for that service.

5.2 Operational
5.2.1 Sender's Perspective
Event sequence
The process from the sender's perspective ("Figure 12: Payment message process from the
sender's perspective" on page 44) is as follows:

1. Mark the message for SWIFTNet FINCopy

If the sender wants to copy a message to the service administrator, then the sender must
insert the SWIFTNet FINCopy service Code specified by the service administrator in Field
103 of Block 3 (user header) of its SWIFTNet FIN user-to-user message.
If there is no field 103 containing a service code, then SWIFTNet FINCopy does not copy the
original message to the service administrator. In this case, SWIFTNet FINCopy delivers the
message directly to the receiver, unless the service administrator has specifically requested
that SWIFTNet FINCopy must copy all messages exchanged within the SWIFTNet FINCopy
CUG.

2. Calculate the Proprietary Authentication Code or generate the relevant digital signature
If the service administrator has specified double authentication in the SWIFTNet FINCopy
service profile, then the sender must use the service administrator destination (CID) from the
service profile to exchange keys with the service administrator. The sender's SWIFTNet FIN
Interface uses relevant information to calculate the Proprietary Authentication Code (PAC),
the digital signature, or both. For detailed information, refer to section A.2.4, "Authentication
Mode".

3. Send the message to the receiver

The sender transmits the message through SWIFTNet FIN. SWIFTNet FIN detects that the
message is a SWIFTNet FINCopy user-to-user message, places it in a temporary queue, and
generates the MT 096 to the service administrator. The MT 096 contains the elements of the
original message that the service administrator defined to be copied in the SWIFTNet
FINCopy service profile.

42 Service Description
 SWIFTNet FINCopy User's Responsibilities

4. Receive information about the message

If SWIFTNet FIN positively acknowledges (ACKs) the message, then the sender may receive
the following information:

• If the service definition includes Sender Notification, then the sender may receive an MT
012 Sender Notification when the payment is authorised.

• The sender may receive an MT 019 Abort Notification for one of the following reasons:

– The MT 096 copy message is aborted.

– The service administrator's response to the copy of the message is an MT 097 rejection
that causes SWIFTNet FIN to reject the queued user-to-user message.

– SWIFTNet FIN has aborted the user-to-user message for a technical reason, outside
the scope of SWIFTNet FINCopy, after the service administrator authorised the
message.
This means that the sender may receive this message after it has received the MT 012.
Field 432 in the MT 019 contains an abort reason code that explains why SWIFTNet FIN
or SWIFTNet FINCopy aborted the original user-to-user message. The sender can use
the code to determine which service aborted the message. See "SWIFTNet FINCopy
Abort Notification" on page 48 for a list of abort reason codes.
The MT 019 also contains the relevant Service Identifier Code.

– The message aborts because the service administrator has not authorised delivery of
the original message for more than 14 days (four days in T&T).
If SWIFTNet FIN negatively acknowledges (NAKs) the message, SWIFTNet FINCopy does
not copy the message. The sender can correct the error and resend the message.

5. Exchange message with the service administrator

If the service allows the exchange of a particular message type with the service
administrator, the sender must be able to process this message type.

16 February 2007 43
SWIFTNet FINCopy

Figure 12: Payment message process from the sender's perspective

MT 103

with SWIFTNet
FINCopy
Service
Identifier
Code

Sender Optionally,
receives Sender
MT 019 receives
Abort ACK NAK MT 012
Notification Sender
Notification

Rejected by Authorised by
Service Administrator Service Administrator

Optionally, Sender
Sender receives
receives MT 019
MT 010 Abort
Non-delivery Notification
Warning

Optionally,
Sender
receives Rejected by SWIFTNet FIN
MT 011 for a technical
Delivery (non SWIFTNet FINCopy)
Notification reason

MT 103

delivered
to receiver
D0110012

5.2.2 Receiver's Perspective

Event sequence
The receiver is involved in SWIFTNet FINCopy in the following way:

1. Receive SWIFTNet FINCopy user-to-user messages

User-to-user messages for the receiver contain the following:

• Field 103 in Block 3 (of the user header)

• optionally, Field 115 (in block 3), which contains information from the service administrator

44 Service Description
 SWIFTNet FINCopy User's Responsibilities

• a PAC trailer, a digital signature, or both, if the service administrator has specified double
authentication in the SWIFTNet FINCopy service profile.

2. Verify the Proprietary Authentication Code or the digital signature

If the service administrator has specified double authentication in the SWIFTNet FINCopy
service profile, then the receiver must use the service administrator destination (CID) from
the service profile to exchange keys with the service administrator.

Note If the SWIFTNet FINCopy service is in T-Copy mode, and the service profile
specifies double authentication, then there cannot be a PAC or a digital signature
from the service administrator for the receiver. This is because there is no
communication between a service administrator and a receiver in this mode.

If the message received contains an empty PAC, then the receiver knows that the fallback
solution agreed amongst the SWIFTNet FINCopy CUG participants applies. For information
about the different fallback modes, see "SWIFTNet FINCopy Service Fallback" on
page 50.

3. Exchange a message with the service administrator

If the Service Profile allows the exchange of a particular message type with the service
administrator, the receiver must be able to process this message type.

16 February 2007 45
SWIFTNet FINCopy

46 Service Description
 Relationship between SWIFTNet FINCopy and SWIFTNet FIN

6 Relationship between SWIFTNet FINCopy

and SWIFTNet FIN
General
This chapter describes the impact of the SWIFTNet FINCopy Service on aspects of the SWIFTNet
FIN messaging service. It covers the following topics:

• message retrievals

• the SWIFTNet FINCopy trigger mechanism

• delivery monitoring and message abort notifications

• SWIFTNet FINCopy abort notifications

• duplicate message avoidance

• message cancellation

• payment release information

• message status reporting

• fallback processing

• test and training

6.1 Message Retrievals

SWIFTNet FINCopy Service and user-to-user messages
Users that participate in a SWIFTNet FINCopy CUG can retrieve user-to-user messages, and the
service administrator can retrieve SWIFTNet FINCopy Service messages (for example, the MT
096 and the MT 097), up to 124 days after SWIFT has acknowledged the messages, as described
in the SWIFTNet FIN Service Description, the SWIFTNet FIN Operations Guide, and as per the
SWIFT Data Retrieval Policy.

Note The service administrator must retrieve a service message from the same server
destination that sent or received the message.

6.2 Message Flow Integrity

6.2.1 SWIFTNet FINCopy Service Trigger Mechanism
SWIFTNet FINCopy service code
The presence of the SWIFTNet FINCopy service code in Field 103 in Block 3 (of the user header)
of the original message triggers the SWIFTNet FINCopy mechanism.
SWIFTNet FINCopy accepts a copy instruction for a message only if the message contains a valid
SWIFTNet FINCopy service code and a valid combination of message parameters (including
sender, receiver, and message type), according to the service administrator's definitions in the
service profile for that service code.

16 February 2007 47
SWIFTNet FINCopy

If there is no field 103 containing a service code, then SWIFTNet FINCopy does not copy the
original message to the service administrator. Instead, SWIFTNet FIN delivers the message
directly to the receiver, unless the service administrator has specifically requested in the service
profile that all messages exchanged in the FINCopy CUG must be copied. If all messages
exchanged within the CUG must be copied, then SWIFT mandates the use of tag 103.
The service-code in Field 103 of Block 3 of the sent message must match the service Identifier of
a valid SWIFTNet FINCopy Service to which the sender and the receiver subscribe. The service
profile must contain the message type. Otherwise, the message receives a Negative
AcKnowledgement (NAK).

6.2.2 Delivery Monitoring and Message Abort Notifications

Abort conditions
SWIFTNet FIN monitors message delivery for the original message. SWIFT does not provide the
service administrator with a message delivery control mechanism (MT 010 and MT 011) for the
delivery of the authorisation and refusal messages.
SWIFTNet FIN aborts the delivery of the message or the copy if any of the conditions given in the
following table is true.

Abort conditions

Service Condition

SWIFTNet The service administrator has rejected the SWIFTNet FINCopy service
FINCopy message.

SWIFTNet FIN The receiver has not logged on to SWIFT and selected SWIFTNet FIN, for
a period of 14 days in live mode, or four days in test and training mode.

SWIFTNet FIN After 11 unsuccessful delivery attempts. (This applies to both the MT 096
and the original message.)

SWIFTNet The service administrator has not sent an authorisation or refusal message
FINCopy and within 14 days.
SWIFTNet FIN

If the message aborts, whether for a SWIFTNet FINCopy reason or a SWIFTNet FIN reason, then
SWIFT uses normal SWIFTNet FIN functionality to notify the sender, by means of the MT 019
Abort Notification. This notification contains the appropriate abort reason codes and the relevant
Service Identifier code.

6.2.3 SWIFTNet FINCopy Abort Notification

Abort reasons
If the service administrator rejects a user-to-user message by means of the MT 097, then
SWIFTNet FINCopy sends an MT 019 Abort Notification to the sender of the original message.
The MT 019 contains an appropriate error code in Field 432, and the relevant Service Identifier
Code. SWIFTNet FIN does not deliver the original message to the receiver.
For a full list of message rejection codes (abort reasons) that apply to field 432 of the MT 019, see
the SWIFTNet FIN System Messages.
The service administrator is responsible for keeping the users that participate in its SWIFTNet
FINCopy CUG informed of the codes used.

48 Service Description
 Relationship between SWIFTNet FINCopy and SWIFTNet FIN

6.2.4 Duplicate Message Avoidance

Possible Duplicate Emission and Possible Duplicate Message trailers
SWIFTNet FIN protects users against message duplication by means of the Possible Duplicate
Emission (PDE) and Possible Duplicate Message (PDM) trailers. These indicators warn a receiver
that a message is possibly a duplicate of a previous one.
Because these indicators form part of the message trailer, SWIFTNet FINCopy includes them in
the information that it copies in the SWIFTNet FIN Copy Service to Service Administrator Message
(MT 096). In this way, SWIFTNet FINCopy also warns the service administrator of the possible
duplicates.
These trailers are part of SWIFTNet FIN functionality and are not specific to SWIFTNet FINCopy.
For full details see the SWIFTNet FIN Service Description.

6.2.5 Message Cancellation

MT 039
The SWIFTNet FIN Cancellation Request Message (MT 039), that a sender can use to cancel a
message that it has previously sent (provided that SWIFTNet FIN has made no attempt to deliver
the message), is not effective within SWIFTNet FINCopy, because SWIFTNet FINCopy copies
messages in real time.

Note The service administrator and the users that participate in its SWIFTNet FINCopy
CUG can agree on specific cancellation procedures. Users that participate in the
SWIFTNet FINCopy CUG must therefore check with the service administrator
whether such procedures are in place.

6.2.6 Payment Release Information

MT 097
When the service administrator sends an authorisation message (MT 097), it has the opportunity
to specify service-administrator-to-sender or service-administrator-to-receiver information (or
both). The service administrator places this information in fields 114 and 115.
The service administrator must select the option to use field 114 during SWIFTNet FINCopy
implementation, because the use of this field generates a separate message, which has message
charge implications. The option to use Field 115, which causes information to be added to an
existing message, is always available to a service administrator.
If a service administrator places a text message in the optional Field 114 of the authorisation
message MT 097, to provide information for the sender of the original user-to-user message, then
SWIFTNet FINCopy issues a Sender Notification (MT 012), which includes this information.
SWIFTNet FINCopy sends the MT 012 to the sender of the original user-to-user message.
If the service administrator uses field 115 to specify service-administrator-to-receiver information,
then SWIFT includes the information in block 3 of the user-to-user message.

Note If the MT 097 contains a rejection code, then the presence of field 114 does not
generate an MT 012 Sender Notification. Also, if the service administrator includes
field 115 in a rejection message, then SWIFTNet FINCopy ignores the information,
because there is no notification to the receiver of a rejected message.

16 February 2007 49
SWIFTNet FINCopy

Duplicate MT 097
If a service administrator sends a duplicate MT 097, then the following occurs:

• if there is a PDE trailer, SWIFTNet FINCopy ignores the second message provided it received
the first MT 097

• If there is no PDE trailer, then the following occurs:

– if the service administrator had already authorised the user-to-user message, then
SWIFTNet FIN sends an MT 015 Delayed NAK to the service administrator, with error code
X37

– if the service administrator had already refused the user-to-user message, then SWIFTNet
FIN sends an MT 015 Delayed NAK to the service administrator, with error code X36

6.2.7 Message Status Reporting to Sender

Error and reason codes
SWIFTNet FIN system messages that provide message, error, or reason codes include specific
SWIFTNet FINCopy codes, as well as codes that refer to reasons outside the scope of SWIFTNet
FINCopy, but within the scope of SWIFTNet FIN processing. The system messages specifically
include the following:

• non-delivery warnings (MT 010), if the message remains undelivered to the receiver at the end
of the obsolescence period

• solicited and unsolicited undelivered message reports (MT 066, MT 082, MT 083)

• message retrievals, including delivery history (MT 021, MT 023)

• abort notifications (MT 019)

SWIFTNet FIN reports the status of a message in Field 431 of non-delivery warnings, undelivered
message reports, and retrieved messages.
For a full list of the message status codes in field 431, see the SWIFTNet FIN System
Messages.
The service administrator must keep the users that participate in its SWIFTNet FINCopy CUG
informed of the current codes.

6.2.8 SWIFTNet FINCopy Service Fallback

Fallback modes
The service administrator must decide upon the fallback mode when it first defines the service.
(See "SWIFTNet FINCopy Service Profile Parameters" on page 58).
The fallback modes are:

• Fallback from Y-Copy mode to closed service state

In this situation, messages that SWIFTNet FINCopy holds while it awaits a response from the
service administrator remain in the temporary queue. New user-to-user SWIFTNet FINCopy
messages, which users that participate in the SWIFTNet FINCopy CUG send while the service
is closed, receive a Negative AcKnowledgement (NAK).

• Fallback from T-Copy mode to closed service state

50 Service Description
 Relationship between SWIFTNet FINCopy and SWIFTNet FIN

Because SWIFTNet FINCopy does not queue messages in T-Copy mode, the impact of this
fallback situation is that new user-to-user SWIFTNet FINCopy messages, which users that
participate in the SWIFTNet FINCopy CUG send while the service is closed, receive a NAK.

• Fallback from Y-Copy mode to bypass mode

A service administrator can bypass the SWIFTNet FINCopy service mechanism in Y-Copy
mode. To do this, the service administrator must ask SWIFT to change the service mode to
Bypass.
SWIFT can only make mode changes if the service state is closed. SWIFTNet FIN NAKs new
user-to-user SWIFTNet FINCopy messages which users that participate in the SWIFTNet
FINCopy CUG send while the service is closed. If SWIFT reopens the service state in Bypass
mode, then it forwards new and existing SWIFTNet FINCopy messages to the receiver, and
replaces original Proprietary Authentication Code (PAC) trailers or digital signatures generated
by the CID destination with empty PACs.

Note An empty PAC trailer indicates to the receiver that the service administrator has
not authorised, or received a copy of, the message.

• Fallback from Y-Copy mode to T-Copy mode

If the service administrator had chosen to use T-Copy mode for fallback from Y-Copy mode,
then SWIFT must still close the service to change the mode. SWIFTNet FIN NAKs new user-
to-user SWIFTNet FINCopy messages that SWIFT receives while SWIFTNet FINCopy is
closed. Within SWIFTNet FINCopy, SWIFT continues to queue messages that require
authorisation. Once SWIFT reopens the service in T-copy mode, it forwards new SWIFT
FINCopy messages to the receiver with no PAC from the service administrator. This is because
T-Copy mode allows only the PAC between sender and service administrator. SWIFT forwards
existing SWIFTNet FINCopy messages with empty PAC trailers. This indicates that the
messages have not undergone the authorisation process, even though SWIFTNet FINCopy
originally received the messages in Y-Copy mode.

Note Absence of a PAC trailer or PKI signature, if the service profile specifies double
authentication, is an indication to the receiver that the service is operating in T-
Copy mode.

6.3 Test and Training

Test and Training within a SWIFTNet FINCopy Service Closed User Group
All users that participate in a SWIFTNet FINCopy Service Closed User Group (CUG) benefit from
a full Test and Training (T&T) environment to exchange test SWIFTNet FINCopy user-to user
messages. In such an environment, SWIFTNet FINCopy copies messages to a service
administrator T&T destination.
The service administrator must take note that SWIFTNet FINCopy copies MT 096 and MT 097
system messages in T&T mode, regardless of the following circumstances:

• whether the service administrator is operating the service in current or future mode

• whether the sender sent the original SWIFTNet FINCopy message in current or future mode
The service administrator must manage the choice of mode for such T&T sessions. The MT 096,
being a system message, is not dependent upon current or future mode, and contains information
that SWIFTNet FINCopy has copied, that is appropriate to the mode that the sender of the original
T&T user-to-user message has selected. For this reason, in test and training, a service

16 February 2007 51
SWIFTNet FINCopy

administrator can receive information that SWIFTNet FINCopy has copied from different users that
participate in the SWIFTNet FINCopy CUG, in both current and future modes.

Note For more information about T&T, see the SWIFTNet FIN Service Description and the
SWIFTNet FIN Operations Guide.

52 Service Description
 Ordering

7 Ordering
Order SWIFT services and products
To use SWIFT services and products, a customer must subscribe to, or order, the relevant services
and products.

Related information
For information about SWIFT's online ordering facility and how to order, see www.swift.com >
Ordering & Support > Ordering.

16 February 2007 53
SWIFTNet FINCopy

54 Service Description
 SWIFT General Terms and Conditions and Liability

8 SWIFT General Terms and Conditions and

Liability

8.1 Application of the SWIFT General Terms and

Conditions
SWIFT General Terms and Conditions
The SWIFT General Terms and Conditions govern the provision and use of the SWIFTNet
FINCopy service. For the latest available version of the SWIFT General terms and Conditions, see
www.swift.com > About SWIFT > Legal > SWIFT offering.

8.2 SWIFT Liability

Liability for SWIFTNet FINCopy messaging
SWIFT accepts liability (whether in contract, tort, or otherwise) to the service administrator and
users that participate in the SWIFTNet FIN Closed User Group (CUG), in connection with the
provision and use of the SWIFTNet FINCopy service, as set out in the SWIFT General Terms and
Conditions, to the extent supplemented or varied by the terms of this chapter.
SWIFT's liability for SWIFTNet FIN messages shall apply mutatis mutandis to the SWIFTNet
FINCopy message processing. This takes into consideration, however, that SWIFTNet FINCopy
message processing is deemed to consist of the delivery of two user-to-user SWIFTNet FIN
messages (that is, one from the sending user that participates in the SWIFTNet FINCopy CUG to
the service administrator and, if so authorised by the service administrator, one from the sending
user that participates in the SWIFTNet FINCopy CUG to the receiving user that participates in the
SWIFTNet FINCopy CUG).
Also, and for the purposes of SWIFTNet FINCopy message processing, timing is defined as
follows:

1. For the delivery of the full or partial copy to the service administrator, the delivery time is
defined as the time elapsed between the acknowledgement of receipt of the original message
by SWIFTNet FIN to the sending user that participates in the SWIFTNet FINCopy CUG and
the availability of the full or partial copy to be forwarded to the service administrator.

2. For the delivery of the original message and approval stamp to the receiver in Y-Copy mode,
the delivery time is defined as the time elapsed between the acknowledgement of receipt of
the delivery authorisation by SWIFT to the service administrator, and the availability of the
original message to be forwarded to the addressee.

3. For the delivery of the optional sender notification in Y-Copy mode, the delivery time is defined
as the time elapsed between the acknowledgement of receipt of the delivery authorisation by
SWIFT to the service administrator, and the availability of the sender notification to be
forwarded to the sender of the user-to-user message.
To avoid any doubt, the responsibilities of the SWIFT user, as a sender or as a receiver of a
SWIFTNet FIN message, as laid down in the SWIFTNet FIN service documentation and, in
particular, the SWIFTNet FIN Service Description, shall also apply mutatis mutandis either to the
service administrator or the user that participates in the SWIFTNet FINCopy CUG (or both, as the
case may be) for messages exchanged in relation to, or in connection with, SWIFTNet FINCopy.

16 February 2007 55
SWIFTNet FINCopy

56 Service Description
 Appendix A - SWIFTNet FINCopy Service Profile

Appendix A

SWIFTNet FINCopy Service Profile

A.1 SWIFTNet FINCopy Service Profile

Example of SWIFTNet FINCopy service parameters
This example is for a SWIFTNet FINCopy Service with the service code COP.

Example

Parameter Value

SWIFTNet FINCopy service code COP

Live Service flag (Live = Y, T&T = N) Y

Service administrator destination (CID) COPYCCLL

Authentication mode (normal = 1, double = 2) 2

Full copy flag (full copy = Y, partial copy = N) N

Currency code CCD

Y-Copy Sender Notification (MT 012) (G=Global, I=Individual, N=None) I

---- ----

Message type (repeat next three parameters for each MT) MT103

List of field tags to be copied 20, 32A

Field tag containing the value date NA

Field tag containing the currency 32A

Message type MT 202

List of field tags to be copied 20, 32A

Field tag containing the value date NA

---- ----

SWIFTNet FINCopy service mode Y-Copy

SWIFTNet FINCopy fallback service Close the

service

SWIFTNet FINCopy server destination - primary COPYCCLA

SWIFTNet FINCopy server destination - secondary COPYCCLB

SWIFTNet FINCopy and the service administrator use the two SWIFTNet FINCopy server
destinations shown to exchange SWIFTNet FINCopy service messages.
The users that participate in the SWIFTNet FINCopy CUG may not see, or require notification
about, SWIFTNet FINCopy service messages for a particular SWIFTNet FINCopy service. For all
operational purposes (for example, Bilateral Key Exchange [BKE] or PAC generation) or
verification of digital signatures, users that participate in a SWIFTNet FINCopy CUG must use the
service administrator destination (CID), which is the third parameter in this example.

16 February 2007 57
SWIFTNet FINCopy

A.2 SWIFTNet FINCopy Service Profile Parameters

A.2.1 SWIFTNet FINCopy Service Code
Field 103
The SWIFTNet FINCopy service code parameter is a unique Identifier which the user that
participates in a SWIFTNet FINCopy CUG inserts into field 103 of the user header, to identify a
message for SWIFTNet FINCopy. SWIFTNet FIN also uses this parameter in undelivered
message reports, for the same purpose. Live and Test and Training (T&T) profiles must share the
same SWIFTNet FINCopy service code. Once the service administrator has defined this
parameter, it cannot be changed.

A.2.2 Live Service Flag

Live or T&T
The live service flag indicates whether the given service definition is for a live copy service or for
a T&T service.

A.2.3 Service Administrator Destination (CID)

SWIFT BIC8
The Service Administrator Destination, formerly known as the Central Institution Destination (CID)
is a valid SWIFT BIC8 that SWIFT assigns to the service administrator. The CID is used in BKE
and for the calculation of Proprietary Authentication Codes (PACs) and digital signatures. The CID
can be the same as the primary server destination.

Note If the service administrator also a user that participates the SWIFTNet FINCopy CUG,
it must use a separate BIC8. If the participation is in test mode only, then an additional
T&T destination is required.

A.2.4 Authentication Mode

Single or double
The authentication mode parameter indicates whether the SWIFTNet FINCopy service is in single
or double authentication mode. Double authentication mode requires PAC trailers or digital
signatures, or both, in SWIFTNet FINCopy messages and (in Y-Copy mode) in message
authorisations and refusals from the service administrator.

MAC and PAC calculation

This PAC <authentication-result> is calculated on the fields extracted from Block 4 of the
message, in the order in which they appear in the message. It is followed by the
<authentication-result> of the message's Message Authentication Code (MAC) trailer, in
the format in which it appears in the message. The following example of an MT 103 shows the
fields that are used to calculate the MAC and PAC respectively.

Fields for MAC calculation

The MAC is calculated on the fields marked in bold in the following message:

58 Service Description
 Appendix A - SWIFTNet FINCopy Service Profile

{1:F01BCITITMMAXXX0012000123}
{2:O1030950040322BNPAFRPPAXXX00120078960403221051U3}
{4:CrLf
:20:1234567890CrLf
:23B:CREDCrLf
:32A:040322EUR450,00CrLf
:50K:MASTERS IMPORTCrLf
RUE DES ARBRES 119CrLf
CAMBRAICrLf
:52A:BNPAFRPPCAMCrLf
:53A:POCIITMM680CrLf
:57A:BCITITMM680CrLf
:59:/P03452032022819 30CrLf
GRAND IMPORTCrLf
PESCARACrLf
:70:/RFB/INV 5591CrLf
:71A:BENCrLf
-}
{5:{MAC:12345678}{CHK:123456789ABC}}

Fields for PAC calculation

The PAC is calculated on the fields marked in bold in the following message:
{1:F01BCITITMMAXXX0012000123}
{2:O1030950040322BNPAFRPPAXXX00120078960403221051U3}
{4:CrLf
:20:1234567890CrLf
:23B:CREDCrLf
:32A:040322EUR450,00CrLf
:50:MASTERS IMPORTCrLf
RUE DES ARBRES 119CrLf
CAMBRAICrLf
:52A:BNPAFRPPCAMCrLf
:53A:POCIITMM680CrLf
:57A:BCITITMM680CrLf
:59:/P03452032022819 30CrLf
GRAND IMPORTCrLf
PESCARACrLf
:70:/RFB/INV 5591CrLf
:71A:BENCrLf
-}
{5:{MAC:12345678}{PAC:98765432}{CHK:123456789ABC}}

A.2.5 Digital Signature Generation

Sender authentication
Because of the way SWIFTNet PKI has been implemented, the sender of the original message
only needs to calculate one PKI signature. This signature covers two sets of data, one for the
receiver of the original message and one for the service administrator. The service administrator
and the receiver of the original message will use the PKI signature to authenticate the sender.

User-to-user message
The following message data will be used:

• Sender BIC8 - the eight character BIC code of the sender of the message

• Receiver BIC8 - the eight-character BIC code of the receiver of the message

• Full block 4 - the full content of block 4 of the FIN message. This is the same block 4 content
that is used to calculate the MAC trailer

16 February 2007 59
SWIFTNet FINCopy

• Random value - this element is mandatory in the case of double authentication of signed
messages, that is, when two digests are generated by the sender. In all other cases it is not
allowed. The purpose of this element is to ensure that, in the case of partial copy, it is not
possible for the service administrator to derive the full block 4 contents

Sender to service administrator

To create the message digest that will be signed for the service administrator, the sender's
application will use the following message data:

• Sender BIC8 - the eight character BIC code of the sender of the message

• Service Administrator (CID) BIC - the eight-character BIC code of the FINCopy Service
Administrator destination (CID) as defined in the FINCopy Service Profile for the service. This
is the destination with which bilateral keys are exchanged today.

• The to-be-copied part of block 4 (full or partial). These are the fields that will be copied to the
Service Administrator in the MT 096 Copy Message. This is the same format of block 4 data
that is currently used to calculate the sender's PAC trailer.

Service administrator to receiver

The service administrator will calculate a PKI signature based on the following input data:

• Service Administrator (CID) BIC - the eight-character BIC code of the FINCopy Service
Administrator destination (CID) as defined in the FINCopy Service Profile for the service. This
is the destination with which bilateral keys are exchanged today.

• Receiver BIC8 - the eight-character BIC code of the receiver of the original message.

• Field 115 (if present) - the contents of the optional field tag 115 (Payment Release Information)
from the Service Administrator to the receiver.

• The fields copied from block 4 of the original message and received in the MT 096 Copy
Message.

• The signature value of the original message if the original message contained a digest for the
user-to-user message.
The service administrator will sign using the certificate associated with the CID destination, that
is, the destination with which the service participants exchange bilateral keys today.

A.2.6 Full Copy Flag

Full or partial copy service
The full copy flag parameter indicates whether the service administrator has defined the SWIFTNet
FINCopy service as a full copy service or a partial copy service. The mode applies to the entire
service (that is, for all message types copied).
If the service is a partial copy service, the SWIFTNet FINCopy service copies only the specified
field tags to the server. If the service is a partial copy service, the service administrator must specify
the List of field tags to be copied for each message type in the service profile. SWIFTNet FINCopy
can copy up to 32 different field tags per message type.

Note Full copy service mode must be used for ISO 15022 message types.

60 Service Description
 Appendix A - SWIFTNet FINCopy Service Profile

A.2.7 Currency Code

Currency code check
The currency code check parameter indicates whether the SWIFTNet FINCopy Service must make
a currency code check on the SWIFTNet FINCopy messages. If the check is required, the service
administrator must specify a field tag that contains the currency code for each message type in
the service profile.

Note Service administrators must not specify currency code checks to ISO 15022 message
types when defining the service profile.

A.2.8 MT 012 Y-Copy Sender Notification

Sender notification
The sender notification parameter indicates, for Y-Copy mode, whether SWIFTNet FINCopy uses
the MT 012 to convey information to the sender of the original user-to-user message. If the service
administrator selects this option, then either all, or selected users that participate in the SWIFTNet
FINCopy CUG, in agreement with the service administrator, receive this message.
The options that are available to the service administrator are as follows:

• General use
SWIFTNet FINCopy always uses the MT 012

• Individual use
The service administrator decides under which circumstances SWIFTNet FINCopy sends an
MT 012.

• Not used
The MT 012 is not available for the specific SWIFTNet FINCopy Service.

A.2.9 Message Types Selected for Copying

Message types
For each SWIFTNet FINCopy service, the service administrator can select up to 25 message types
to be copied.

A.2.10 SWIFTNet FINCopy Service Mode

Normal service mode
The SWIFTNet FINCopy service mode parameter indicates the normal service mode, Y-Copy, or
T-Copy. In Y-Copy mode, SWIFTNet FINCopy delivers the original message to the receiver only
after receipt of an authorisation message from the service administrator. In T-Copy mode,
SWIFTNet FINCopy delivers the original message to the receiver, and sends a full or partial copy
to the service administrator.

16 February 2007 61
SWIFTNet FINCopy

A.2.11 SWIFTNet FINCopy Fallback Service Mode

Emergency service
SWIFTNet FINCopy fallback service mode is the mode in which the service can operate if there
is a disaster or emergency. For more information about the different types of fallback modes, see
"SWIFTNet FINCopy Service Fallback" on page 50.

A.2.12 SWIFTNet FINCopy Server Destinations

Service administrator server destinations
The SWIFTNet FINCopy server destination parameters are the service administrator server
destinations to which SWIFTNet FINCopy forwards MT 096 SWIFTNet FINCopy to service
administrator messages. There must be at least one server destination for each Slice Processor
(SP), for each service in the network. Each service is said to be owned by its respective SP. Live
and T&T services must have separate server destinations. The live service must have at least two
server destinations (one for each SP). Services with low traffic volumes can operate with a single
server destination. The service administrator must agree this with SWIFT in advance. The T&T
service must have at least two server destinations (one for each SP), unless the service
administrator and SWIFT have agreed to operate with a single server destination.

Note The MT 097 SWIFTNet FINCopy Message Authorisation/Refusal Notification must

always be issued by the same server destination (that is, BIC8) that received the
corresponding MT 096.

Additional server destinations

Additional server destinations must be dedicated destinations.

62 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

Appendix B

Case Studies for SWIFTNet Phase 1

B.1 Purpose of this Appendix

Sample transaction messages
This appendix contains the messages that relate to a sample transaction that is profiled in
"Transaction Profile" on page 64 and illustrates the SWIFTNet Phase 1 behaviour. The sample
transaction shows the various extra fields and trailers for the different SWIFTNet FINCopy
conditions described in sections "Messages, Y-Copy Mode: Authorised Payment" on page 65
to "Messages, T-Copy Mode" on page 76.
To explain the processes, these case studies show all the messages involved in the various
SWIFTNet FINCopy modes. In reality, users that participate in a SWIFTNet FINCopy CUG and
the service administrator, have different perspectives on the SWIFTNet FINCopy service, as
"Figure 13: SWIFTNet FINCopy user's perspective" and "Figure 14: Service administrator's
perspective" illustrate. Users that participate in a SWIFTNet FINCopy CUG see the payment
message process. The service administrator sees the system message dialogue with SWIFTNet
FINCopy.

Figure 13: SWIFTNet FINCopy user's perspective

MT 103 MT 103 MT 103

Sender with held in SWIFTNet FINCopy delivered Receiver
SWIFTNet to
FINCopy receiver
Service
D0110013

Identifier
Code

16 February 2007 63
SWIFTNet FINCopy

Figure 14: Service administrator's perspective

SWIFTNet
FINCopy

MT 096 MT 097

D0110014
Service Administrator

Note The messages shown in this appendix have some header and trailer block fields on
separate lines. This is only for purposes of illustration and must not be taken as
indications of <carriage return - line feed> within the messages.

B.2 Transaction Profile

Case study parameters
Sections "Messages, Y-Copy Mode: Authorised Payment" on page 65 to "Messages, T-Copy
Mode" show the messages that result from the following transaction processed by various
SWIFTNet FINCopy services.
For this purpose, the following is assumed:

• that the transaction takes place in a country with country code CC

• that the currency in the country is CC Dollars, with a currency code of CCD

• that a service administrator with primary server destination INSTCC2AXXX has established an
RTGS system that uses SWIFTNet FINCopy

• that two users that participate in the SWIFTNet FINCopy CUG are Senderbank
SNDRCC2AXXX and Receiverbank RCVRCC2AXXX

64 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

• that on 01 September 2007, Senderbank, on behalf of its customer A. Payer Inc., effects a
same-day-value payment of CCD 10,000.00 in favour of A. Payee Inc., in account with
Receiverbank.
In these case studies, the SWIFTNet FINCopy service profile contains the following parameters:

• the SWIFTNet FINCopy service Identifier code is COP

• double authentication

• partial copy

• SWIFTNet FINCopy must copy fields 20 and 32A in the MT 103

Other SWIFTNet FINCopy service profile parameters vary according to the different case studies.

B.3 Messages, Y-Copy Mode: Authorised Payment

Y-Copy mode example
In this case study, the service administrator has specified Y-Copy mode in the SWIFTNet FINCopy
service profile. The SWIFTNet FINCopy service is in normal operations mode, and the service
administrator has authorised the payment message.
The following figures show the sequence of messages:

• "Figure 15: MT 103 Single customer credit transfer that Senderbank has prepared and
transmitted to SWIFTNet FIN." and transmitted to SWIFTNet FIN.

• "Figure 16: MT 096 SWIFTNet FIN Copy service to service administrator message".

• "Figure 17: MT 097 SWIFTNet FINCopy message authorisation/refusal notification", that the
service administrator has returned. It shows the authorisation code, and contains information
for both the sender and the receiver.

• "Figure 18: MT 103 Single customer credit transfer message as delivered to Receiverbank".
The message contains additional information in the header block from the service
administrator. The original PAC that Senderbank prepared, has been exchanged for the second
PAC that the service administrator has prepared.

• "Figure 19: MT 012 Sender notification". This message contains information for Senderbank
from the service administrator.

16 February 2007 65
SWIFTNet FINCopy

Figure 15: MT 103 Single customer credit transfer that Senderbank has prepared and transmitted to
SWIFTNet FIN.

MT 103
(As Sent)

{1:F01SNDRCCAAXXX0123000456}

{2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:
SWIFTNet FINCopy Message User
Service Identifier Reference (MUR)
20:TRANSREF
Code Ignored by SWIFTNet
as defined in the FIN and SWIFTNet
23B:CRED
Service Profile. FINCopy, but copied
If invalid, will to the Service
32A:070901CCD10000.00
cause message Administrator
to be NAKed within the MT 096
50K:A PAYER INC

59:A PAYEE INC

71A: BEN

-}

{5:{MAC:12AB34CD}
PAC trailer {PAC:34CD56EF}
based on BKE
between {CHK:123456789ABC}}
Senderbank and
the Service
Administrator,
but added to
message from
Senderbank
to Receiverbank

D0110015

66 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

Figure 16: MT 096 SWIFTNet FIN Copy service to service administrator message

SWIFTNet FINCopy MT 096 SWIFTNet FIN Copy Service

Service Identifier to Service Administrator
Code
copied from {1:F01INSTCC2AAXXX0246000987}
the MT 103
after validation {2:O0961200070901DYLPXXXXEXXX0000
by SWIFTNet 1399900709011201S}
FINCopy {3:{103:COP}{108:SNDRCC2AA1234456}
Header of }
MT 103
{4:

{1:F01SNDRCC2AAXXX0123000456}
Message User
Reference (MUR) {2:I103RCVRCC2AXXXXU}
Ignored by
SWIFTNet FIN and {3:{103:COP}{108:12345678}}
SWIFTNet FINCopy,
{4:
but copied to the
Service Administrator 20:TRANSREF
within the MT 096
32A:070901CCD10000.00
Text fields
of MT 103 -}
As partial copy {5:
has been specified
only the fields {MAC:12AB34CD}
listed in the
service profile {PAC:34CD56EF}
have been copied
{MRF:070901120000070901SNDRCC2A
AXXX0123000456}}
MAC trailer
copied from }
MT 103 {5:CHK:987654321DEF}{SYS:12000709
01SNDRCC2AAXXX01234000456}}
PAC trailer
copied from
MT 103, for
processing by User message reference trailer Envelope
Service Administrator inserted by SWIFTNet FINCopy
D0110016
containing information from MT 103

16 February 2007 67
SWIFTNet FINCopy

Figure 17: MT 097 SWIFTNet FINCopy message authorisation/refusal notification

MT 097 Service Administrator to

SWIFTNet FINCopy (Authorised Message)
SWIFTNet FINCopy
Service Identifier {1:F01INSTCC2AAXXX0246123456}
Code
copied from {2:I097SWFTXXXXXXXXS}
the MT 096
{4:

{103:COP}
User message
reference {109:070901120000070901SNDRCC2AAXXX
copied from 0123000456}
the MT 096
{451:0} Information from
Service Administrator
{114:AUTH REF 123456} to Senderbank

Accept-Reject {115:SETTLEMENT REF 123456}

field Information from
0 = Accepted } Service Administrator
1 = Rejected to Receiverbank
{5:

{PAC:A1B2C3F4}

{CHK:246135789FED}}

NEW PAC trailer

calculated by the Service Administrator, based on BKE
between Service Administrator and Receiverbank
D0110017

68 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

Figure 18: MT 103 Single customer credit transfer message as delivered to Receiverbank

MT 103
(As Delivered)

{1:F01RCVRCC2AAXXX2345987654}

{2:O1031200070901SNDRCC2AAXXX012300
SWIFTNet FINCopy 04560709011205U}
Service Identifier Message User
Code Reference (MUR)
{3:{103:COP}{108:12345678}
Ignored by
SWIFTNet FIN and
{115:SETTLEMENT REF 123456}}
SWIFTNet FINCopy,
but copied to the
{4:
Information from Service Administrator
Service Administrator within the MT 096
20:TRANSREF
copied from
MT 097 into 23B:CRED
block 3
(user header) 32A:070901CCD10000.00

50K:A PAYER INC

59:A PAYEE INC

71A:BEN

-}

{5:{MAC:12AB34CD}

PAC trailer {PAC:A1B2C3F4}

copied from
MT 097 {CHK:135792468BCD}}

D0110018

16 February 2007 69
SWIFTNet FINCopy

Figure 19: MT 012 Sender notification

MT 012 Sender Notification

{1:F01SNDRCC2AAXXX0123000888}

{2:O0121205070901DYLPXXXXEXXX0000139990
0709011206S}

{4:

{175:0900}
Message User
Reference (MUR) {106:070901SNDRCC2AAXXX012300456}
identifying
Senderbank's {108:12345678}
original message
{102:RCVRCC2AXXXX}

{103:COP}

{114:AUTH REF 123456} Information from

SWIFTNet FINCopy Service Administrator
Service Identifier to Senderbank
}
Code copied from
{5:CHK:246813579ABC}{SYS:1205070901INST MT 097
CC2AAXXX0246123456}}

D0110019

Note Because SWIFTNet FINCopy service profiles for the case studies in this appendix
specify partial copy, the MT 103 trailers copied in the MT 096, and illustrated in figures
16, 21, and 27, do not include the checksum trailer. However, if the service profiles
had specified full copy, then the checksum trailer would be present, between the
Proprietary Authentication Code (PAC) and the Message Reference (MRF) trailer.

B.4 Messages, Y-Copy Mode: Rejected Payment

Message sequence
In this case study, the SWIFTNet FINCopy service is still in Y-Copy mode, but the service
administrator decides to reject the payment message.
The message sequence is as follows:

• "Figure 20: MT 103 Single customer credit transfer message from Senderbank".

• "Figure 21: MT 096 SWIFTNet FIN Copy service to service administrator message".

70 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

Note These messages are identical to those in the case study in "Messages, Y-Copy
Mode: Authorised Payment" on page 65.

• "Figure 22: MT 097 Rejection message" shows the MT 097, in which Field 451 indicates that
the service administrator has rejected the proposed transaction, and that SWIFTNet FINCopy
must delete the payment message and not deliver it to Receiverbank. This message also
contains a code, in Field 432, giving the abort reason.

• "Figure 23: MT 019 Abort notification to Senderbank".

Figure 20: MT 103 Single customer credit transfer message from Senderbank

MT 103(As Sent)

{1:F01SNDRCC2AAXXX0123000456}

{2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:

20:TRANSREF

23B:CRED

32A:0709012CCD10000.00

50K:A PAYER INC

SWIFTNet FINCopy 59:A PAYEE INC

Service Identifier
Code, and PAC 71A:BEN
trailer,
as shown in -}
Figure 15,
are the additional {5:{MAC:12AB34CD}
elements of the
payment message {PAC:34CD56EF}
as specified for
SWIFTNet FINCopy. {CHK:123456789ABC}}

As Senderbank is unaware that this message will be

rejected by the Service Administrator, this message is
identical to the one shown in the case study in
D0110020

Section B.3

16 February 2007 71
SWIFTNet FINCopy

Figure 21: MT 096 SWIFTNet FIN Copy service to service administrator message

MT 096 SWIFTNet FIN Copy Service

to Service Administrator
{1:F01INSTCC2AAXXX0246000987}

{2:O0961200070901DYLPXXXXEXXX0000
1399900709011201S}
SWIFTNet FINCopy
Service Identifier {3:{103:COP}{108:SNDRCC2AA1234456}
Code }
{4:

{1:F01SNDRCC2AAXXX0123000456}
Headers of
MT 103 {2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:
20:TRANSREF
Text fields
of MT 103 32A:070901CCD10000.00
-}
{5:
MAC trailer {MAC:12AB34CD}
PAC trailer {PAC:34CD56EF}

User message {MRF:070901120002070901SNDRCC2A

AXXX0123000456}}
reference trailer
}
{5:CHK:987654321DEF}{SYS:12000709
01SNDRCC2AAXXX01234000456}}

This message, sent to the Service Administrator by Envelope

SWIFTNet FINCopy, is identical to the one shown
D0110021
in the case study in Section B.3

72 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

Figure 22: MT 097 Rejection message

MT 097 Service Administrator

To SWIFTNet FINCopy
SWIFTNet FINCopy (Rejected Message)
Service Identifier {1:F01INSTCC2AAXXX0246123456}
Code
copied from {2:I097SWFTXXXXXXXXS}
the MT 096

User message {4:

reference
copied from {103:COP}
the MT 096
{109:070901120002070901SNDRCC2AAXXX
0123000456}
Accept-Reject
field {451:1}
0 = Accepted
1 = Rejected {432:66}

}
Abort-reason
code {5:
from a range of
code numbers {PAC:A1B2C3F4}
reserved for
SWIFTNet FINCopy {CHK:987654321CBA}}

(The meaning of
each code in this
range is defined
by the Service
Administrator and
known to banks
in the FINCopy
CUG)
NEW PAC trailer,
calculated by the Service Administrator, based on BKE
between Service Administrator and Receiverbank

As the MT 097 is a rejection message and the MT 103 will be

D0110022
deleted this PAC will be discarded by SWIFTNet FINCopy

16 February 2007 73
SWIFTNet FINCopy

Figure 23: MT 019 Abort notification to Senderbank

MT 019 Abort Notification

{1:F01SNDRCC2AAXXX0247000888}

{2:O0191205070901DYLRXXXXEXXX000013991
0709011206S}
Identification
of original {4:
payment
message {175:1200}

{106:SNDRCC2AAXXX0123000456}

{102:RCVRCC2AXXX}
Abort reason {432:66}
copied from
MT 097 {619:COP}

}
Service Identifier
Code of original {5:CHK:123456789ABC}{SYS:1205070901
payment message INSTCC2AAXXX0246123456}}

The Abort Notification MT 019 is a standard SWIFTNet FIN

message, used in this instance by SWIFTNet FINCopy to
inform Senderbank of the Service Administrator's decision
to reject the payment message. The abort reason code
number, from the range reserved for SWIFTNet FINCopy

D0110023
use, tells Senderbank why the rejection has happened.

B.5 Messages, Fallback to Bypass Mode

Fallback service mode
This case study shows the operation of the SWIFTNet FINCopy service in one of the fallback
service modes. The service administrator has already, as an emergency procedure, requested
SWIFT to switch to the declared fallback mode. SWIFT has closed the service state, changed the
mode from Y-Copy mode to Bypass mode, and reopened the service state.
The message sequence is as follows:

• "Figure 24: MT 103 Single customer credit transfer message from Senderbank". This MT 103
is identical to those in Sections "Messages, Y-Copy Mode: Authorised Payment" on page 65
and "Messages, Y-Copy Mode: Rejected Payment" on page 70, because a SWIFTNet FINCopy
mode change has no impact on the sender. Indeed, the sender does not need to know that
SWIFT has changed the mode.

74 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

However, if Senderbank had sent the MT 103 when the service state was closed for the mode
change, Senderbank would have received a negative acknowledgement (NAK) for the
message.

Note The change to a fallback mode may, however, have significant impact on the real-
time gross settlement or netting service for which the customer uses the SWIFTNet
FINCopy service. The service administrator must ensure that all users that
participate in the SWIFTNet FINCopy CUG receive appropriate notification.

• "Figure 25: MT 103 as delivered to Receiverbank" shows the MT 103 that SWIFTNet FINCopy
has forwarded and SWIFTNet FIN has delivered directly to Receiverbank. The message has
not been held in a temporary queue. SWIFTNet FINCopy has removed the PAC in the original
MT 103, which is based on Bilateral Key Exchange (BKE) between Senderbank and the service
administrator. However, because there has been no communication with the service
administrator, the PAC trailer is empty. For the same reason, field 115 is not added to the header
block of the MT 103.

Figure 24: MT 103 Single customer credit transfer message from Senderbank

MT 103
(As Sent)

{1:F01SNDRCC2AAXXX0123000456}

{2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:

20:TRANSREF

23B:CRED

32A:070901CCD10000.00

50K:A PAYER INC

SWIFTNet FINCopy 59:A PAYEE INC
Service Identifier
Code, and PAC 71A:BEN
trailer,
as shown in -}
Figure 15,
are the additional {5:{MAC:12AB34CD}
elements of the
payment message {PAC:34CD56EF}
as specified for
SWIFTNet FINCopy. {CHK:123456789ABC}}

Operationally, nothing has changed for Senderbank

and therefore the message sent is identifical to the
ones shown in the case studies in Section B.3 and
B.4.
D0110024

16 February 2007 75
SWIFTNet FINCopy

Figure 25: MT 103 as delivered to Receiverbank

MT 103
(As Delivered)

{1:F01RCVRCC2AAXXX2345987654}

SWIFTNet FINCopy {2:O1031200070901SNDRCC2AAXXX01230

Service Identifier 004560709011201U} Message User
Code Reference (MUR)
{3:{103:COP}{108:12345678}} Ignored by
SWIFTNet FIN and
{4: SWIFTNet FINCopy,
now known to
20:TRANSREF Senderbank and
Receiverbank,
23B:CRED but NOT to the
Service Administrator
32A:070901CCD10000.00

50K:A PAYER INC

59:A PAYEE INC

Empty PAC trailer
SWIFTNet FINCopy 71A:BEN
has removed the
PAC intended for the -}
Service Administrator,
but, since there {5:{MAC:12AB34CD}
has been no
communication {PAC:}
with the Service
Administrator with {CHK:864297531AFB}}
the service in
Bypass mode,
cannot add a PAC
for Receiverbank
The Empty PAC trailer is the indication to Receiver-
bank that the message has NOT been copied to the
Service Administrator

D0110025

B.6 Messages, T-Copy Mode

T-Copy mode
This case study shows the operation of the SWIFTNet FINCopy service in T-Copy mode. This can
be either the normal mode, as specified in the SWIFTNet FINCopy service profile, or the fallback
mode for a service that normally operates in Y-Copy mode.
The message sequence is as follows:

• "Figure 26: MT 103 Single customer credit transfer message from Senderbank" (identical to
those in the preceding sections).

• "Figure 27: MT 096 SWIFTNet FIN Copy service to service administrator message" (also
identical to those in preceding sections).

• "Figure 28: MT 103 Single customer credit transfer message as delivered" (forwarded to
Receiverbank by SWIFTNet FINCopy). SWIFTNet FINCopy forwards this message as soon as
it has copied the information required for the MT 096. However, SWIFTNet FINCopy removes

76 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

the PAC trailer that was present in the original is no PAC between the service administrator and
the receiver.

Figure 26: MT 103 Single customer credit transfer message from Senderbank

MT 103
(As Sent)

{1:F01SNDRCC2AAXXX0123000456}

{2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:

20:TRANSREF

23B:CRED

32A:070901CCD10000.00

50K:A PAYER INC

SWIFTNet FINCopy 59:A PAYEE INC
Service Identifier
Code, and PAC 71A:BEN
trailer,
as shown in -}
Figure 15,
are the additional {5:{MAC:12AB34CD}
elements of the
payment message {PAC:34CD56EF}
as specified for
SWIFTNet FINCopy. {CHK:123456789ABC}}

Again, the message from Senderbank is identical to

the message in the preceding case studies
D0110026

16 February 2007 77
SWIFTNet FINCopy

Figure 27: MT 096 SWIFTNet FIN Copy service to service administrator message

MT 096 SWIFTNet FIN Copy Service

to Service Administrator
{1:F01INSTCC2AAXXX0246000987}

{2:O0961200070901DYLPXXXXEXXX0000
1399900709017201S}
SWIFTNet FINCopy {3:{103:COP}{108:SNDRCC2AA1234456}
Service Identifier }
Code
{4:

{1:F01SNDRCC2AAXXX0123000456}
Headers of
MT 100 {2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}
{4:
20:TRANSREF
Text fields
of MT 100 23B:CRED

32A:070901CCD10000.00
-}

{5:
MAC trailer {MAC:12AB34CD}
PAC trailer {PAC:34CD56EF}

User message {MRF:070901120002070901SNDRCC2A

reference trailer AXXX0123000456}}
}

{5:CHK:987654321DEF}{SYS:12000709
01SNDRCC2AAXXX01234000456}}
Envelope

In this T-Copy mode case study, this message, sent to

the Service Administrator by SWIFTNet FINCopy, is identical
D0110027
to the one shown in the Y-Copy mode case study in Section B.3.
However, the Service Administrator cannot send a response.

78 Service Description
 Appendix B - Case Studies for SWIFTNet Phase 1

Figure 28: MT 103 Single customer credit transfer message as delivered

MT 103
(As Delivered)

{1:F01RCVRCC2AAXXX2345987654}

{2:O1031200070901SNDRCC2AAXXX01230
SWIFTNet FINCopy 004560709011201U}
Service Identifier
Code {3:{103:COP}{108:12345678}}

{4:

20:TRANSREF

23B:CRED

32A:070901CCD10000.00

50K:A PAYER INC

59:A PAYEE INC

71A:BEN

-}

{5:{MAC:12AB34CD}

{CHK:249765318DAB}}

No PAC trailer
SWIFTNet FINCopy has removed the PAC
prepared by Senderbank and copied to the
Service Administrator.

Since there is no communication between This message has not been held in a temporary
the Service Administrator and Receiverbank queue but forwarded by SWIFTNet FINCopy for
in T-Copy mode, there cannot be a PAC delivery to Receiverbank once the information

D0110028
trailer in the message delivered to needed for the MT 096 to the Service
Receiverbank. Administrator has been copied.

16 February 2007 79
SWIFTNet FINCopy

80 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

Appendix C

Case Studies for SWIFTNet Phase 2

C.1 Purpose of this Appendix

Sample transaction messages
This appendix contains the messages that relate to a sample transaction that is profiled in
"Transaction Profile" on page 82 illustrating the SWIFTNet Phase 2 behaviour. The sample
transaction shows the various extra fields and trailers for the different SWIFTNet FINCopy
conditions described in sections "Messages, Y-Copy Mode: Authorised Payment" on page 83
to "Messages, T-Copy Mode" on page 94.
To explain the processes, these case studies show all the messages involved in the various
SWIFTNet FINCopy modes. In reality, users that participate in the SWIFTNet FINCopy CUG and
the service administrator, have different perspectives on the SWIFTNet FINCopy service, as
"Figure 29: SWIFTNet FINCopy user's perspective" and "Figure 30: Service administrator's
perspective" illustrate. Users that participate in the SWIFTNet FINCopy CUG see the payment
message process. The service administrator sees the system message dialogue with SWIFTNet
FINCopy.

Figure 29: SWIFTNet FINCopy user's perspective

MT 103 MT 103 MT 103

Sender with held in SWIFTNet FINCopy delivered Receiver
SWIFTNet to
FINCopy receiver
Service
D0110013

Identifier
Code

16 February 2007 81
SWIFTNet FINCopy

Figure 30: Service administrator's perspective

SWIFTNet
FINCopy

MT 096 MT 097

D0110014
Service Administrator

Note The messages shown in this appendix have some header and trailer block fields on
separate lines. This is only for purposes of illustration and must not be taken as
indications of <carriage return - line feed> within the messages.

C.2 Transaction Profile

Case study parameters
Sections "Messages, Y-Copy Mode: Authorised Payment" on page 83 to "Messages, T-Copy
Mode" on page 94 show the messages that result from the following transaction processed by
various SWIFTNet FINCopy services.
For this purpose, the following is assumed:

• that the transaction takes place in a country with country code CC

• that the currency in the country is CC Dollars, with a currency code of CCD

• that a service administrator with primary server destination INSTCC2AXXX has established an
RTGS system that uses SWIFTNet FINCopy

• that two users that participate in the SWIFTNet FINCopy CUG are Senderbank
SNDRCC2AXXX and Receiverbank RCVRCC2AXXX

82 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

• that on 01 September 2007, Senderbank, on behalf of its customer A. Payer Inc., effects a
same-day-value payment of CCD 10,000.00 in favour of A. Payee Inc., in account with
Receiverbank.
In these case studies, the SWIFTNet FINCopy service profile contains the following parameters:

• the SWIFTNet FINCopy service Identifier code is COP

• double authentication

• partial copy

• SWIFTNet FINCopy must copy fields 20 and 32A in the MT 103

Other SWIFTNet FINCopy service profile parameters vary according to the different case studies.

C.3 Messages, Y-Copy Mode: Authorised Payment

Y-Copy mode example
In this case study, the service administrator has specified Y-Copy mode in the SWIFTNet FINCopy
service profile. The SWIFTNet FINCopy service is in normal operations mode, and the service
administrator has authorised the payment message.
The following figures show the sequence of messages:

• "Figure 31: MT 103 Single customer credit transfer that Senderbank has prepared and
transmitted to SWIFTNet FIN." and transmitted to SWIFTNet FIN.

• "Figure 32: MT 096 SWIFTNet FIN Copy service to service administrator message".

• "Figure 33: MT 097 SWIFTNet FINCopy message authorisation/refusal notification", that the
service administrator has returned. It shows the authorisation code, and contains information
for both the sender and the receiver.

• "Figure 34: MT 103 Single customer credit transfer message as delivered to Receiverbank".
The message contains additional information in the header block from the service
administrator.

• "Figure 35: MT 012 Sender notification". This message contains information for Senderbank
from the service administrator.

16 February 2007 83
SWIFTNet FINCopy

Figure 31: MT 103 Single customer credit transfer that Senderbank has prepared and transmitted to
SWIFTNet FIN.

MT 103
(As Sent)

{1:F01SNDRCCAAXXX0123000456}

{2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:
SWIFTNet FINCopy Message User
Service Identifier Reference (MUR)
20:TRANSREF
Code Ignored by
as defined in the SWIFTNet FIN and
23B:CRED
Service Profile. SWIFTNet FINCopy,
If invalid, will but copied to the
32A:070901CCD10000.00
cause message Service Administrator
to be NAKed within the MT 096
50K:A PAYER INC

59:A PAYEE INC

71A: BEN

-}

{5:

{CHK:123456789ABC}}

<signature block>

Signature block
contains signature
allowing verification
of message
authenticity and
integrity

D0110029

84 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

Figure 32: MT 096 SWIFTNet FIN Copy service to service administrator message

SWIFTNet FINCopy
MT 096 SWIFTNet FIN Copy Service
Service Identifier to Service Administrator
Code {1:F01INSTCC2AAXXX0246000987}
copied from
the MT 103 {2:O0961200070901DYLPXXXXEXXX0000
after validation 1399900709011201S}
by SWIFTNet
FINCopy {3:{103:COP}{108:SNDRCC2AA1234456}
}
Header of {4:
MT 103
{1:F01SNDRCC2AAXXX0123000456}
Message User
Reference (MUR) {2:I103RCVRCC2AXXXXU}
Ignored by
SWIFTNet FIN and {3:{103:COP}{108:12345678}}
SWIFTNet FINCopy,
{4:
but copied to the
Service Administrator 20:TRANSREF
within the MT 096
32A:070901CCD10000.00
Text fields
of MT 103 -}
As partial copy {5:
has been specified
only the fields {MRF:070901120000070901SNDRCC2A
listed in the AXXX0123000456}}
service profile
have been copied }

{5:CHK:987654321DEF}{SYS:12000709
01SNDRCC2AAXXX01234000456}}

<signature block>
Signature block
copied from the
original message

User message reference trailer Envelope

inserted by SWIFTNet FINCopy
D0110030
containing information from MT 103

16 February 2007 85
SWIFTNet FINCopy

Figure 33: MT 097 SWIFTNet FINCopy message authorisation/refusal notification

MT 097 Service Administrator

to SWIFTNet FINCopy
SWIFTNet FINCopy (Authorised Message)
Service Identifier {1:F01INSTCC2AAXXX0246123456}
Code
copied from {2:I097SWFTXXXXXXXXS}
the MT 096
{4:

{103:COP}
User message
reference {109:070901120000070901SNDRCC2AAXXX
copied from 0123000456}
the MT 096
{451:0} Information from
Service Administrator
{114:AUTH REF 123456} to Senderbank

Accept-Reject {115:SETTLEMENT REF 123456}

field Information from
0 = Accepted } Service Administrator
1 = Rejected to Receiverbank
{5:

{CHK:246135789FED}}

<signature block>
Signature block
generated by the
Service Administrator

D0110031

86 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

Figure 34: MT 103 Single customer credit transfer message as delivered to Receiverbank

MT 103
(As Delivered)

{1:F01RCVRCC2AAXXX2345987654}

{2:O1031200070901SNDRCC2AAXXX012300
SWIFTNet FINCopy 04560709011205U}
Service Identifier Message User
Code Reference (MUR)
{3:{103:COP}{108:12345678}
Ignored by
SWIFTNet FIN and
{115:SETTLEMENT REF 123456}}
SWIFTNet FINCopy,
but copied to the
{4:
Information from Service Administrator
Service Administrator within the MT 096
20:TRANSREF
copied from
MT 097 into 23B:CRED
block 3
(user header) 32A:070901CCD10000.00

50K:A PAYER INC

59:A PAYEE INC

71A:BEN

-}

Signature block 1 {CHK:135792468BCD}}

generated by the
Sender of MT 103 <signature block 1>

<signature block 2>

Signature block 2
copied from MT 097

D0110032

16 February 2007 87
SWIFTNet FINCopy

Figure 35: MT 012 Sender notification

MT 012 Sender Notification

{1:F01SNDRCC2AAXXX0123000888}

{2:O0121205070901DYLPXXXXEXXX0000139990
0709011206S}

{4:

{175:0900}
Message User
Reference (MUR) {106:070901SNDRCC2AAXXX012300456}
identifying
Senderbank's {108:12345678}
original message
{102:RCVRCC2AXXXX}

{103:COP}

{114:AUTH REF 123456} Information from

SWIFTNet FINCopy Service Administrator
Service Identifier to Senderbank
}
Code copied from
{5:CHK:246813579ABC}{SYS:1205070901INST MT 097
CC2AAXXX0246123456}}

D0110019

Note Because SWIFTNet FINCopy service profiles for the case studies in this appendix
specify partial copy, the MT 103 trailers copied in the MT 096, and illustrated in figures
32, 37, and 43, do not include the checksum trailer. However, if the service profiles
had specified full copy, then the checksum trailer would be present.

C.4 Messages, Y-Copy Mode: Rejected Payment

Message sequence
In this case study, the SWIFTNet FINCopy service is still in Y-Copy mode, but the service
administrator decides to reject the payment message.
The message sequence is as follows:

• "Figure 36: MT 103 Single customer credit transfer message from Senderbank".

• "Figure 37: MT 096 SWIFTNet FIN Copy service to service administrator message".

88 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

Note These messages are identical to those in the case study in "Messages, Y-Copy
Mode: Authorised Payment" on page 83.

• "Figure 38: MT 097 Rejection message" shows the MT 097, in which Field 451 indicates that
the service administrator has rejected the proposed transaction, and that SWIFTNet FINCopy
must delete the payment message and not deliver it to Receiverbank. This message also
contains a code, in Field 432, giving the abort reason.

• "Figure 39: MT 019 Abort notification to Senderbank".

Figure 36: MT 103 Single customer credit transfer message from Senderbank

MT 103 (As Sent)

{1:F01SNDRCC2AAXXX0123000456}

{2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:

20:TRANSREF

23B:CRED

32A:0709012CCD10000.00

50K:A PAYER INC

SWIFTNet FINCopy 59:A PAYEE INC

Service Identifier
Code, 71A:BEN
as shown in
Figure 31. -}

{5:

{CHK:123456789ABC}}

<signature block>

Signature block
contains signature
allowing verification
of message
authenticity and
integrity As Senderbank is unaware that this message will be
rejected by the Service Administrator, this message is
identical to the one shown in the case study in
D0110034

Section B.3

16 February 2007 89
SWIFTNet FINCopy

Figure 37: MT 096 SWIFTNet FIN Copy service to service administrator message

MT 096 SWIFTNet FIN Copy Service

to Service Administrator
{1:F01INSTCC2AAXXX0246000987}

{2:O0961200070901DYLPXXXXEXXX0000
1399900709011201S}
SWIFTNet FINCopy
Service Identifier {3:{103:COP}{108:SNDRCC2AA1234456}
Code }
{4:

{1:F01SNDRCC2AAXXX0123000456}
Headers of
MT 103 {2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:
20:TRANSREF
Text fields
of MT 103 32A:070901CCD10000.00
-}
{5:

User message {MRF:070901120002070901SNDRCC2A

reference trailer AXXX0123000456}}
}

{5:CHK:987654321DEF}{SYS:12000709
01SNDRCC2AAXXX01234000456}}

<signature block>
Signature block
copied from the
original message
Envelope

This message, sent to the Service Administrator by

SWIFTNet FINCopy, is identical to the one shown
D0110035
in the case study in Section B.3

90 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

Figure 38: MT 097 Rejection message

MT 097 Service Administrator

to SWIFTNet FINCopy
SWIFTNet FINCopy (Rejected Message)
Service Identifier
{1:F01INSTCC2AAXXX0246123456}
Code
copied from
{2:I097SWFTXXXXXXXXS}
the MT 096

User message {4:

reference
copied from {103:COP}
the MT 096
{109:070901120002070901SNDRCC2AAXXX
0123000456}
Accept-Reject
field {451:1}
0 = Accepted
1 = Rejected {432:66}

}
Abort-reason
code {5:
from a range of
code numbers {CHK:987654321CBA}}
reserved for
SWIFTNet FINCopy <signature block>

(The meaning of
each code in this
range is defined
by the Service
Administrator and
known to banks
in the SWIFTNet
FINCopy CUG)
Signature block
As the MT 097 is a rejection message and the MT 103
will be deleted, this signature block will be discarded by
SWIFTNet FINCopy.

D0110036

16 February 2007 91
SWIFTNet FINCopy

Figure 39: MT 019 Abort notification to Senderbank

MT 019 Abort Notification

{1:F01SNDRCC2AAXXX0247000888}

{2:O0191205070901DYLRXXXXEXXX000013991
0709011206S}
Identification
of original {4:
payment
message {175:1200}

{106:SNDRCC2AAXXX0123000456}

{102:RCVRCC2AXXX}
Abort reason {432:66}
copied from
MT 097 {619:COP}

}
Service Identifier
Code of original {5:CHK:123456789ABC}{SYS:1205070901
payment message INSTCC2AAXXX0246123456}}

The Abort Notification MT 019 is a standard SWIFTNet FIN

message, used in this instance by SWIFTNet FINCopy to
inform Senderbank of the Service Administrator's decision
to reject the payment message. The abort reason code
number, from the range reserved for SWIFTNet FINCopy

D0110023
use, tells Senderbank why the rejection has happened.

C.5 Messages, Fallback to Bypass Mode

Fallback service mode
This case study shows the operation of the SWIFTNet FINCopy service in one of the fallback
service modes. The service administrator has already, as an emergency procedure, requested
SWIFT to switch to the declared fallback mode. SWIFT has closed the service state, changed the
mode from Y-Copy mode to Bypass mode, and reopened the service state.
The message sequence is as follows:

• "Figure 40: MT 103 Single customer credit transfer message from Senderbank". This MT 103
is identical to those in Sections "Messages, Y-Copy Mode: Authorised Payment" on page 83
and "Messages, Y-Copy Mode: Rejected Payment" on page 88, because a SWIFTNet FINCopy
mode change has no impact on the sender. Indeed, the sender does not need to know that
SWIFT has changed the mode.

92 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

However, if Senderbank had sent the MT 103 when the service state was closed for the mode
change, Senderbank would have received a negative acknowledgement (NAK) for the
message.

Note The change to a fallback mode may, however, have significant impact on the real-
time gross settlement or netting service for which the customer uses the SWIFTNet
FINCopy service. The service administrator must ensure that all users that
participate in the SWIFTNet FINCopy CUG receive appropriate notification.

Figure 40: MT 103 Single customer credit transfer message from Senderbank

MT 103
(As Sent)

{1:F01SNDRCC2AAXXX0123000456}

{2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:

20:TRANSREF

23B:CRED

32A:070901CCD10000.00

50K:A PAYER INC

SWIFTNet FINCopy 59:A PAYEE INC
Service Identifier
Code, 71A:BEN
as shown in Figure 31.
-}

{5:

{CHK:123456789ABC}}

Signature block <signature block>

contains signature
allowing verification
of message authenti-
city and integrity
Operationally, nothing has changed for Senderbank
and therefore the message sent is identifical to the
ones shown in the case studies in Section B.3 and
B.4.
D0110038

• "Figure 41: MT 103 as delivered to Receiverbank" shows the MT 103 that SWIFTNet FINCopy
has forwarded and SWIFTNet FIN has delivered directly to Receiverbank. The message has
not been held in a temporary queue. The presence of an empty PAC trailer indicates to the
receiver that there has been no communication with the service administrator as the service is

16 February 2007 93
SWIFTNet FINCopy

in bypass mode and no copy has been made. For the same reason, field 115 is not added to
the header block of the MT 103.

Figure 41: MT 103 as delivered to Receiverbank

MT 103
(As Delivered)

{1:F01RCVRCC2AAXXX2345987654}

{2:O1031200070901SNDRCC2AAXXX01230
SWIFTNet FINCopy 004560709011201U}
Service Identifier Message User
Code Reference (MUR)
{3:{103:COP}{108:12345678}} Ignored by
SWIFTNet FIN and
{4: SWIFTNet FINCopy,
now known to
20:TRANSREF Senderbank and
Receiverbank,
23B:CRED but NOT to the
Service Administrator
32A:070901CCD10000.00

50K:A PAYER INC

59:A PAYEE INC

Empty PAC trailer
The presence of an 71A:BEN
empty PAC trailer
indicates to the -}
receiver that there has
been no communication {5:
with the Service
Administrator as the {PAC:}
service is in bypass
mode and no copy {CHK:864297531AFB}}
has been made.
<signature block>

D0110039

C.6 Messages, T-Copy Mode

T-Copy mode
This case study shows the operation of the SWIFTNet FINCopy service in T-Copy mode. This can
be either the normal mode, as specified in the SWIFTNet FINCopy service profile, or the fallback
mode for a service that normally operates in Y-Copy mode.
The message sequence is as follows:

• "Figure 42: MT 103 Single customer credit transfer message from Senderbank" (identical to
those in the preceding sections).

• "Figure 43: MT 096 SWIFTNet FIN Copy service to service administrator message" (also
identical to those in preceding sections).

• "Figure 44: MT 103 Single customer credit transfer message as delivered" (forwarded to
Receiverbank by SWIFTNet FINCopy). SWIFTNet FINCopy forwards this message as soon as
it has copied the information required for the MT 096.

94 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

Figure 42: MT 103 Single customer credit transfer message from Senderbank

MT 103
(As Sent)

{1:F01SNDRCC2AAXXX0123000456}

{2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}

{4:

20:TRANSREF

23B:CRED

32A:070901CCD10000.00

50K:A PAYER INC

SWIFTNet FINCopy 59:A PAYEE INC
Service Identifier
Code, 71A:BEN
as shown in
Figure 31. -}

{5:

{CHK:123456789ABC}}

Signature block <signature block>

contains signature
allowing verification
of message authenti-
city and integrity
Again, the message from Senderbank is identical to
the message in the preceding case studies

D0110040

16 February 2007 95
SWIFTNet FINCopy

Figure 43: MT 096 SWIFTNet FIN Copy service to service administrator message

MT 096 SWIFTNet FIN Copy Service

to Service Administrator
{1:F01INSTCC2AAXXX0246000987}

{2:O0961200070901DYLPXXXXEXXX0000
1399900709017201S}
SWIFTNet FINCopy
Service Identifier {3:{103:COP}{108:SNDRCC2AA1234456}
Code }
{4:

{1:F01SNDRCC2AAXXX0123000456}
Headers of
MT 103 {2:I103RCVRCC2AXXXXU}

{3:{103:COP}{108:12345678}}
{4:
20:TRANSREF
Text fields
of MT 103 23B:CRED

32A:070901CCD10000.00
-}

{5:

User message {MRF:070901120002070901SNDRCC2A

reference trailer AXXX0123000456}}

}
{5:CHK:987654321DEF}{SYS:12000709
01SNDRCC2AAXXX01234000456}}
<signature block>

Envelope

In this T-Copy mode case study, this message, sent to the

Service Administrator by SWIFTNet FINCopy, is identical to
D0110041
the one shown in the Y-Copy mode case study in Section B.3.
However, the Service Administrator will not send a response.

96 Service Description
 Appendix C - Case Studies for SWIFTNet Phase 2

Figure 44: MT 103 Single customer credit transfer message as delivered

MT 103
(As Delivered)

{1:F01RCVRCC2AAXXX2345987654}

{2:O1031200070901SNDRCC2AAXXX01230
SWIFTNet FINCopy 004560709011201U}
Service Identifier
Code {3:{103:COP}{108:12345678}}

{4:

20:TRANSREF

23B:CRED

32A:070901CCD10000.00

50K:A PAYER INC

59:A PAYEE INC

71A:BEN

-}

{5:

{CHK:249765318DAB}}

<signature block>

Since there is no communication between This message has not been held in a temporary
the Service Administrator and Receiverbank queue but forwarded by SWIFNet FINCopy for
in T-Copy mode, there is no sign from the delivery to Receiverbank once the information
Service Administrator for Receiverbank. needed for the MT 096 to the Service Administrator
has been copied.

D0110042

16 February 2007 97
SWIFTNet FINCopy

98 Service Description
 Appendix D - Service Administrators Operations Guide

Appendix D

Service Administrators Operations Guide

D.1 General
D.1.1 Scope of this Appendix
SWIFTNet FINCopy procedures
This appendix describes the procedures relevant to SWIFTNet FINCopy. See www.swift.com >
Ordering & Support for detailed information concerning SWIFTSupport and ordering processes.

D.2 Definition of Procedures

Procedures
This section lists the following types of procedures in alphabetical order:

• SWIFTNet FINCopy service: normal procedures

• SWIFTNet FINCopy service: emergency procedures

D.2.1 SWIFTNet FINCopy Service: Normal Procedures

Normal procedures

Procedures

Procedure Explanation

Add SWIFTNet FINCopy To add a SWIFT user to a new or existing SWIFTNet FINCopy
user Closed User Group (CUG).

Define SWIFTNet FINCopy To set up a SWIFTNet FINCopy service profile.

Service Parameters

Modify SWIFTNet FINCopy To modify an existing SWIFTNet FINCopy service profile.

Service Parameters

Open SWIFTNet FINCopy The request from a service administrator for SWIFT to activate
Service a SWIFTNet FINCopy service, for either live or test and
training operation, in the agreed mode (Y-Copy, T-Copy, or
Bypass).

Order SWIFTNet FIN To order SWIFTNet FIN interface software.

Interface Software

Order Documentation To order the documentation that users require to operate a

SWIFTNet FINCopy service.

Report Ordering Problem To report delays or misunderstandings about a purchase

order that needs a follow up or a solution (or both).

Report Technical Problem To report difficulty or inability to connect to the SWIFT network,
or any other technical or operational problem.

16 February 2007 99
SWIFTNet FINCopy

Procedure Explanation

Withdraw SWIFTNet To remove a SWIFTNet FINCopy user from the CUG at a

FINCopy user specific date, at the request of the service administrator.

D.2.2 SWIFTNet FINCopy Service: Emergency Procedures

Restrictions
The use of emergency procedures is restricted to either of the following:

• unforeseen critical events with severe time constraints

• planned contingency testing

Emergency procedures apply to exceptional circumstances. At all other times, users that
participate in a SWIFTNet FINCopy CUG must follow normal procedures.

Allowable Downtime Window

Emergency modifications to the SWIFTNet FINCopy service cannot take place during an Allowable
Downtime Window (ADW). An ADW is a scheduled period during which SWIFT does not guarantee
service availability. SWIFT normally uses ADWs for planned changes, with the consequent
interruption of services. SWIFT usually schedules ADWs outside business hours, at weekends.

D.2.2.1 SWIFTNet FINCopy Service: Unforeseen Critical Emergency Events

Exceptional procedures

Procedures

Procedure Explanation

Emergency Modify An emergency request by a service administrator for a change

SWIFTNet FINCopy Mode of SWIFTNet FINCopy mode for the live or test and training
or State SWIFTNet FINCopy service. This means a change from the
mode in which the SWIFTNet FINCopy service is working (for
example, from Y-copy mode to Bypass mode).

Emergency Withdraw An emergency request by a service administrator to remove a

SWIFTNet FINCopy user SWIFTNet FINCopy user from the CUG, with immediate
effect.

D.2.2.2 SWIFTNet FINCopy Service: Planned Contingency Testing

Exceptional procedures
There are two types of planned contingency testing, as follows:

• mode change to perform system trial tests

• mode change to perform emergency tests

The service administrator must notify SWIFT of these tests beforehand as indicated in the following
table.

100 Service Description

 Appendix D - Service Administrators Operations Guide

Procedures

Procedures Explanation

Mode Change for System A service administrator wants to test the ability of itself and the
Trialing users that participate in its SWIFTNet FINCopy CUG to
operate in fallback mode.
The service administrator must send a fax to its owning CSC,
at least four business days prior to the test, and must indicate
the local date and time of the requested mode change.
On the day of the mode change, the service administrator
must telephone its owning CSC and follow the emergency
procedures described in procedure P5. (See D.4, "Processes
and Procedures".)

Mode Change to Perform A service administrator wants to simulate an emergency

Emergency Tests situation and test the emergency procedures.
On the day of the mode change, the service administrator
must telephone its owning CSC and follow the standard
emergency procedures. In this case, no prior warning is
required.
SWIFT recommends regular testing, as follows:

• 3 tests during service deployment per CSC

• 2 tests per year, after the service has gone live

For more information about this procedure, see "Telephone Authentication Procedure" on
page 107.

D.3 Data Maintenance

Table contents
"Table 12: SWIFTNet FINCopy service data maintenance" and "Table 13: SWIFTNet FINCopy
user administration data maintenance" provide information about the different types of requests
which users that participate in a SWIFTNet FINCopy CUG and service administrators make to
SWIFT. These requests fall into the following categories:

• ordering and data maintenance

• technical problems
For each request type, the table shows the procedure number in the second column. See section
"Processes and Procedures" on page 103 for details of these procedures.
If applicable, the table also shows the form which the user that participates in a SWIFTNet FINCopy
CUG, or the service administrator must use, and the time that SWIFT requires to implement the
request.

Note This section does not cover connectivity equipment. However, for planning purposes,
customers must consider the time to install and commission such equipment,
together with the timing of any configuration changes to interface software.

16 February 2007 101

SWIFTNet FINCopy

D.3.1 Ordering and Data Maintenance

SWIFTNet FIN
For information about the SWIFTNet FIN messaging service, see the SWIFTNet FIN
documentation, and www.swift.com.
Customers can order documentation and interface software on www.swift.com.

SWIFTNet FINCopy service

Table 12: SWIFTNet FINCopy service data maintenance

Request Procedure to Request form to use Estimated time to

follow implement

define SWIFTNet P3 Service Profile Form 84 days

FINCopy service (Service Administrator)
parameters

modify SWIFTNet P3 SWIFTNet Service Profile 2 to 8 weeks

FINCopy service Form (Service (depending on the
parameters Administrator) type of change
required)

open SWIFTNet P3 by e-mail from one of the 14 days

FINCopy service authorised approvers

order additional ICC P3 SWIFTNet FIN Security 14 days

sets or ICCs Equipment

emergency modify P5 Telephone Authorisation 45 minutes

SWIFTNet FINCopy Procedure plus
mode Emergency Request
Confirmation

SWIFTNet FINCopy user administration

Table 13: SWIFTNet FINCopy user administration data maintenance

Request Procedure to Request form to be used Estimated Time to

follow implement

add SWIFTNet P1 SWIFTNet Service 14 days

FINCopy user Subscription Form (e- changes are effected
MSSF) at weekends

withdraw SWIFTNet P2 SWIFTNet Terminate 14 days

FINCopy user Market Infrastructure changes are effected
Subscription Form at weekends

emergency withdraw P5 Telephone Authorisation 45 minutes

SWIFTNet FINCopy Procedure plus Terminate
user Market Infrastructure
Subscription Form

102 Service Description

 Appendix D - Service Administrators Operations Guide

D.4 Processes and Procedures

Introduction
This section explains the generic processes and procedures identified in the preceding section.
For each generic process and procedure, this section lists and explains the specific steps involved.

D.4.1 P1: Order from a SWIFTNet FINCopy User approved by

the Service Administrator, to COS by Form
Process
The process for adding a user to a SWIFTNet FINCopy CUG is as follows:

1. The SWIFT user completes the SWIFTNet Service Subscription Form (e-MSSF).

2. SWIFT sends an approval request to the service administrator.

3. One of the service administrator authorised approvers must approve the e-MSSF and send
it back to COS.

4. COS implements the service subscription and confirms implementation to the service
administrator and to the SWIFT user, by e-mail.

Note COS cannot process a request for activation unless it meets the following criteria:

• COS has received the required e-MSSF duly approved by the service
administrator

• the SWIFT user is allowed to send and receive the messages exchanged
within the SWIFTNet FINCopy Closed User Group (CUG)

Implementation timetable
Implementations always occur during the weekend. The earliest possible implementation of an
order is the second weekend following the date of submission. Orders must be validated by SWIFT
as being correct and approved by the service administrator. Duly approved e-MSSF forms must
be received at the latest by 10:00 GMT on the Tuesday preceding the requested implementation
date.

Example
If SWIFT receives the approved e-MSSF on Tuesday 6 November 2007, before 10:00 GMT, then
SWIFT will activate the user in the SWIFTNet FINCopy CUG during the ADW on 10 November
2007. If SWIFT receives the approved e-MSSF on Tuesday, 6 November 2007, after 10:00 GMT,
then SWIFT will activate the user in the SWIFTNet FINCopy CUG during the ADW on 17 November
2007.

D.4.2 P2: Order from a Service Administrator to COS by Form

Process
The process for withdrawing a user from a SWIFTNet FINCopy CUG is as follows:

1. The service administrator or the user completes the SWIFTNet Terminate Subscription Form.

16 February 2007 103

SWIFTNet FINCopy

2. SWIFTNet Terminate Subscription Forms completed by a user must be approved by one of

the service administrator's authorised approvers.

3. COS implements the procedure and confirms implementation to the service administrator and
to the customer by e-mail.

Note Service administrators must use process P1 to arrange for SWIFT to readmit a
previously withdrawn user to the SWIFTNet FINCopy CUG.

Implementation timetable
Implementations always occur during the weekend. The earliest possible implementation of an
order is the second weekend following the date of submission. Orders must be validated by SWIFT
as being correct and approved by the service administrator. Duly approved SWIFTNet Terminate
Subscription Forms must be received at the latest by 10:00 GMT on the Tuesday preceding the
requested implementation date.

Example
If SWIFT receives the approved SWIFTNet Terminate Subscription Form on Tuesday 6 November
2007, before 10:00 GMT, then SWIFT will activate the user in the SWIFTNet FINCopy CUG during
the ADW on 10 November 2007. If SWIFT receives the approved SWIFTNet Terminate
Subscription Form on Tuesday, 6 November 2007, after 10:00 GMT, then SWIFT will activate the
user in the SWIFTNet FINCopy CUG during the ADW on 17 November 2007.

D.4.3 P3: Order from a Service Administrator to Market

Infrastructures Service Management by Form
Introduction
Customers use the P3 order form to do the following:

• define and modify SWIFT SWIFTNet FINCopy service parameters

• order telephone authentication cards

• notify the start-up date of a new SWIFTNet FINCopy service

D.4.3.1 P3: To Define or Modify SWIFTNet FINCopy Service Parameters

Process
The following process defines or modifies SWIFTNet FINCopy service parameters:

1. The service administrator and SWIFT Payments Clearing Business Management agree the
definition or change.

2. The service administrator completes the Service Profile Form and sends or faxes it to Global
Sales Services. The order must arrive in good time.

3. Global Sales Services, together with Payments Clearing Business Management, reviews the
content of the order.

4. Global Sales Services confirms receipt of the form to the service administrator by MT 999,
fax, or mail, and, in the case of a modification, confirms the time needed for implementation.

104 Service Description

 Appendix D - Service Administrators Operations Guide

5. Ordinarily, SWIFT implements modifications to SWIFTNet FINCopy parameters within two to

eight weeks (depending on the type of change required), during an Allowable Downtime
Window (ADW).

Note Customers cannot modify the following SWIFTNet FINCopy service parameters:

• the server destinations

• the service administrator destination (CID)

• the SWIFTNet FINCopy Service Identifier code

6. If changes affect the users in a SWIFTNet FINCopy CUG, then the service administrator must
allow the users sufficient time to change the appropriate parameters in their own systems.

D.4.3.2 P3 - To order telephone authentication cards

Process
The process for ordering a telephone authentication card is as follows:

1. The service administrator completes the SWIFTNet FIN Security Equipment Order Form.

2. SWIFT confirms receipt of the form to the service administrator by MT 999, fax, or mail.

Note For more information about this process, see "Telephone Authentication
Cards" on page 108 for further details.

D.4.3.3 P3: To Open the SWIFTNet FINCopy Service

Process
The process for opening the SWIFTNet FINCopy service is as follows:

1. The service administrator and SWIFT Payments Clearing Business Management agree a
date to open the live, or test and training SWIFTNet FINCopy service.

2. The service administrator completes a written request, and sends or faxes the request to
Payments Clearing Business Management and Customer Projects.

3. SWIFT confirms receipt of the request to the service administrator by MT 999, fax, or mail.

4. SWIFT activates the SWIFTNet FINCopy service, and confirms activation to the service
administrator by MT 999, fax, or mail.

Note SWIFT activates SWIFTNet FINCopy services only during Allowable Downtime
Windows (ADWs).

D.4.4 P4: Problem Report to CSC

Process
Standard SWIFTSupport processes should be used for SWIFTNet FINCopy service related
issues:

• For more information, see the SWIFTSupport Service Description.

16 February 2007 105

SWIFTNet FINCopy

D.4.5 P5: Emergency Request from the Service Administrator

to CSC by Authenticated Telephone Call
Introduction
This procedure enables the following:

• emergency modification of SWIFTNet FINCopy mode

• emergency modification of multiple server mapping

• emergency withdrawal of a user from a SWIFTNet FINCopy CUG

Note The service administrator uses this procedure for emergency changes only (that
is, critical events or time constraints).

To ensure that only the service administrator can request emergency updates, SWIFT uses
exchanged passwords to authenticate the service administrator calling the SWIFT Customer
Service Centre (CSC).
For more information about this procedure, see "Telephone Authentication Procedure" on
page 107, for more details.

Emergency request from the service administrator to the CSC

The process for processing an emergency request from the service administrator to CSC is as
follows:

1. The service administrator calls the CSC with the emergency request.

2. The parties identify each other by means of a password exchange.

3. The CSC gives the service administrator a case reference number.

4. The service administrator also confirms the request by fax to CSC stating in capital letters at
the start of the fax: EMERGENCY REQUEST CONFIRMATION.

Note SWIFT provides a template for emergency request confirmations.

5. The CSC confirms the change to the service administrator by fax.

D.4.6 P6: Problem Report from a SWIFTNet FINCopy User to

the Local Settlement Help Desk by Telephone
Procedure
This procedure is specific to particular SWIFTNet FINCopy Services:

• For more information, contact the relevant service administrator.

106 Service Description

 Appendix D - Service Administrators Operations Guide

D.5 Stress Testing SWIFTNet FINCopy

Individual and global stress testing
There are two types of SWIFTNet FINCopy stress tests, as follows:

• Stress tests for individual users that participate in a SWIFTNet FINCopy CUG. As part of its test
and training qualification, a service administrator may request users that participate in a
SWIFTNet FINCopy CUG to prove that they can achieve their respective peak hour throughput.
The service administrator plans and runs these tests at its best convenience. Individual user
stress tests must also respect the rules about peak message volumes at the service
administrator level that are defined in the remainder of this section.

• Global system stress testing. This means that all users that participate in a SWIFTNet FINCopy
Closed User Group (CUG) are testing the CUG's peak hour throughput, which can have a
significant impact on the SWIFT network (especially at the service administrator level),
depending on the volumes.
For all types of stress testing, the following rules apply:

• For peak hour under 5,000 messages (at the service administrator level)
The service administrator is free to organise these tests on its own (no need to co-ordinate with
SWIFT).

• For peak hour between 5,000 and 10,000 messages (at the service administrator level)
The service administrator must request a testing date and time from SWIFT Capacity Planning.
The service administrator must make this request at least eight weeks before the desired period,
and must send the request by fax or MT 999. Capacity Planning issues, by fax or MT 999, a
time to execute the tests. (Depending on network load, it may be necessary for tests to take
place during weekends). Exceptionally, the service administrator can arrange a notification
period of less than eight weeks on a best-effort basis.

• For peak hour over 10,000 messages (at the service administrator level)
The service administrator must request a testing date and time from SWIFT Capacity Planning.
The service administrator must send the request, by fax or MT 999, to SWIFT Capacity
Planning, with at least 8-weeks notice. Capacity Planning notifies the service administrator, by
fax or MT 999, of the date on which the tests can take place. Exceptionally, the service
administrator can arrange a notification period of less than eight weeks on a best-effort basis.

Note Capacity Planning reserves the right to cancel tests (for example, if a major,
unexpected problem arises).

D.6 Telephone Authentication Procedure

Introduction
This section explains the authentication part of procedure P5. Service administrators use this
procedure for emergency telephone requests to the SWIFT Customer Service Centre (CSC).

Recommendation
As with all emergency procedures, SWIFT recommends regular testing of this authentication
procedure.

16 February 2007 107

SWIFTNet FINCopy

D.6.1 Telephone Authentication Cards

D.6.1.1 Introduction

Password cards
SWIFT authenticates the telephone call by means of a hexadecimal password that is used only
once. This password, called Phone Key (PK), is the result of a calculation based on several
parameters, entered by the user, and stored inside the telephone authentication card.
To authenticate telephone calls, the service administrator must have a Basic Card Reader (BCR)
and USER Integrated Circuit Cards (ICCs). These enable the service administrator to do the
following:

• to prove to its counterpart, the CSC, that the requester of the change is an authorised person
at the service administrator's location (that is, that the request is genuine)

• to check that the other party is the CSC

D.6.1.2 Definitions

Terms

List of terms

Authentication Security One or more security officers at the service administrator's

Officer location, that are responsible for the control and management
of telephone authentication cards and BCRs, and for liaison
with the owning CSC.

Owning CSC The CSC that is responsible for the customisation of all sets
of telephone authentication cards for the service
administrator and other CSCs.

D.6.1.3 Administration

Terms
For a service administrator, administration of telephone authentication cards is straightforward.
SWIFT gives ownership of a set of telephone authentication cards to the owning CSC, which will
administer and maintain the cards according to the service administrator's requirements.

Note In these circumstances, a set of telephone authentication cards contains at least one
User Security Officer (USOF card) and one User card. SWIFT does not include the
User Key Management Officer (UKMO) card, because there is no need for BKE
(Bilateral Key Exchange).

Further Details
For further explanation of the above terminology, see the SWIFTNet FIN Security Guide.
The owning CSC and the service administrator agree dates for testing the authentication
procedure, for test and training and, subsequently, for live operation.

108 Service Description

 Appendix D - Service Administrators Operations Guide

D.6.1.4 Ordering Procedures

Security officer and user cards

The service administrator determines, with the assistance of Global Sales Services, the number
of USOF (User Security Officer) and USER cards to order.

Note For security and operational reasons, SWIFT advises the service administrator to
order a backup card for each card that it requests.

Order quantity
SWIFT recommends that the service administrator orders at least the following cards:

• 6 USOF cards (2 for each CSC)

• 8 or 12 USER ICCs, according to the following options:

– 2 for each CSC (2 x 3 = 6), plus 2 for the service administrator

– 3 for each CSC (3 x 3 = 9), plus 3 for the service administrator

The owning CSC ships USER cards to the Authentication Security Officers at the service
administrator's location, and USOF and USER cards to the other CSCs.
The Authentication Security Officers, and the other CSCs, must acknowledge receipt of the cards
to the owning CSC by MT 999, fax, mail, or internal electronic mail (between the CSCs).
On receipt of the acknowledgements, the owning CSC ships the two PIN mailers for the USER
cards to the authentication security officers. The owning CSC also ships the PIN mailers for the
USOF cards to the other CSCs.
Each CSC starts a service administrator file for the cards, and keeps the PINs in a secure place.

D.6.1.5 Operational Procedures

Phone-key generation
The following step-by-step procedure for Phone Key generation must be conducted
simultaneously at the calling service administrator's location and at the called CSC.
If a sensitive update is necessary, then the service administrator must call the owning CSC and
give customer identification.

Note If the service administrator calls outside the owning CSC's normal workinghours, then
SWIFT automatically routes the telephone call to another CSC.

Activation sequence
The service administrator activates the BCR by inserting the USER card and the correct PIN code.
See "Table 14: phone key generation, steps 1 to 7" in the Phone Key (PK) generation procedure.
The owning CSC asks the service administrator to provide the next PK challenge (that is, a random
4-digit number). "Table 15: Phone key generation, step 8" shows step 8 of this process.
CSC staff ask the service administrator to read out the characters displayed on the first line of the
Basic Card Reader (BCR) display. If the characters match the display on the CSC reader, then
the service administrator has successfully authenticated itself.

16 February 2007 109

SWIFTNet FINCopy

Table 14: phone key generation, steps 1 to 7

Step Action Display

1 Insert the USER ICC into the BCR CONNECTED MODE?

The BCR displays ->

2 Press the following keys in sequence DAEA#

The BCR displays -> ENTER PIN 1
1st TRY:.....

3 Type the PIN 1 associated with the #

USER ICC inserted in the BCR, ENTER PIN 2
followed by ->
1st TRY:.....
The BCR displays ->
#
Type the PIN 2 associated with the
USER ICC inserted in the BCR, SWIFT SLS MANAGEMENT
followed by ->
Once you have typed the PIN 2 and #,
the BCR displays ->

4 Press -> #
and the BCR displays -> SLS MANAGEMENT
SK GENERATION

5 Press -> #
and the BCR displays -> LOGICAL TERMINAL
BANKCCLLZ (example)

6 Press -> #
and the BCR displays -> APPLICATION
LOGIN

7 Press -> #
and the BCR displays -> LSN:

The owning CSC then reads out next eight characters, characters, from the second line of the
BCR display, to authenticate itself to the service administrator.
After successful authentication of both parties, the service administrator makes its request.

Note The owning CSC informs the other CSCs of the next PK sequence number to be
used.

Authentication process failure

If the characters do not match the CSC display, then the authentication process has failed. The
two parties can restart the procedure at their discretion.

Table 15: Phone key generation, step 8

Step Action Display

8 Type the 4-digit challenge as given by the CSC NNNN

staff -> followed by -> # SK: 5977 B45C
The BCR then displays the phone key as follows: 1/2 741E A8E0 (example)
->

110 Service Description

 Appendix D - Service Administrators Operations Guide

Note To avoid misinterpretation of alphabetic characters, SWIFT recommends the use of

international spelling (for example, A Alpha, B Bravo, C Charlie, as listed in Table
16).

Recommended code words

Table 16: International spelling code words

Letter Code word

A ALPHA

B BRAVO

C CHARLIE

D DELTA

E ECHO

F FOXTROT

Note Each telephone call relating to an emergency request should be authenticated.

D.6.1.6 Troubleshooting

Introduction
The purpose of this section is to provide the service administrator with some guidance if the BCR
fails to operate correctly. The following examples describe some problems that may occur when
the BCR is used to authenticate the telephone call.

Note The Basic Card Reader (BCR) and Integrated Circuit Cards (ICCs) are robust and
reliable devices, and, whatever operational difficulties the service administrator may
incur, the owning CSC staff are always available to assist customers to find the correct
solution.

For more detailed information, see the SWIFT Manual Card Readers User Guide .

Examples
The following are sample authentication problems:

1. Unsuccessful authentication
The Phone Key (PK) that the BCR generates may not be the same as the one that the owning
CSC expects. This results in an authentication failure, which occurs because the card reader
has stored the incorrect ICC kernel version.
The service administrator must immediately update this parameter to its correct value. If the
service administrator does not know this value it must contact the owning CSC.

2. BCR refuses to generate a PK

This may be caused by one of the following reasons:

• No PIN code was entered.

• The PIN code is not correct.

16 February 2007 111

SWIFTNet FINCopy

• The ICC is blocked (following more than three unsuccessful attempts to enter the PIN
code). In this case the service administrator must use the backup card and send the blocked
ICC to the owning CSC.

• The BCR battery needs to be replaced.

3. Lost or stolen BCR

The BCR contains no secret information. Therefore, following the loss of a BCR, the service
administrator simply replaces it with the backup card and orders a new one from SWIFT.
The act of moving to a new BCR implies the need to update, and possibly modify for security
reasons, the kernel version on the replacement card reader.

4. Lost or stolen cards

Should any USER card be lost or stolen, the service administrator, or CSC, must immediately
take protective action to prevent that ICC from use by unauthorised persons.
For USER ICCs, access codes are calculated from secret information stored in the ICCs, and
known as ICC Kernels. Eight ICC Kernels are defined for each USER ICC.
The owning CSC manages the ICC kernel version in current use, and must make the kernel
version information known to every other involved party (that is, the service administrator and
the other CSCs). To notify the service administrator, the owning CSC sends an MT 999, fax,
or mail, to the two nominated security officers.
If cards are lost, one of the parties (either the service administrator or the owning CSC) calls
the other and states that the kernel version must be changed to the next version number.
One of the parties (either the service administrator or the owning CSC) asks the other to
provide confirmation of the necessary change of kernel version from a second person (for
example, the second authentication security officer at the service administrator's location).
The owning CSC updates the kernel version and notifies all other involved parties of the new
kernel version for the service administrator's USER cards.

Note To avoid a situation in which there is no backup USER card, the service
administrator must order new cards before only one USER card remains.

D.7 Forms
Introduction
All necessary forms, including the SWIFTNet Service Subscription Form (e-MSSF), are available
from SWIFT's Regional Commercial Administrators or www.swift.com.

D.7.1 SWIFTNet Service Profile

SWIFTNet FINCopy operational parameters
The service administrator uses the Service Profile Form to communicate to SWIFT general
information about itself, and some SWIFTNet FINCopy operational parameters, including the
following:

• definition of the message types and fields to be copied, routing restrictions, and other service
profile parameters

• message billing

112 Service Description

 Appendix D - Service Administrators Operations Guide

• details of the service administrator and two or three authorised approvers at the service
administrator's location (the approvers will be responsible for the service's implementation and
operation)

• addition of dedicated server destinations

Note Although this form is intended for the service administrator to confirm the SWIFTNet
FINCopy service profile that it has agreed with SWIFT, the service administrator
must also arrange for all uses that participate in the SWIFTNet FINCopy Closed User
Group (CUG) to receive this information. All users that participate in a SWIFTNet
FINCopy CUG must configure the service profile parameters correctly in the
SWIFTNet FIN interfaces.

D.7.2 Emergency Request Confirmation

Confirmation of verbal request
The service administrator uses the Emergency Request Confirmation Form only to confirm to
SWIFT the emergency withdrawal of a user from a SWIFTNet FINCopy CUG, or the modification
of the SWIFTNet FINCopy service mode. The service administrator must fax the form to the
appropriate CSC after it has made a verbal request by authenticated telephone call.

D.7.3 SWIFTNet Subscription Form

Permission to use SWIFTNet FINCopy
A SWIFT user uses the SWIFTNet FINCopy Subscription Form (e-MSSF) to notify SWIFT that it
wants to do the following:

• join a SWIFTNet FINCopy CUG

• acknowledge and agree with the terms and conditions of its use of the SWIFTNet FINCopy
service.

D.7.4 SWIFTNet Terminate Subscription Form

SWIFTNet FINCopy user withdrawal
The service administrator uses the SWIFTNet Terminate Subscription Form to notify SWIFT of the
withdrawal of a user from a SWIFTNet FINCopy CUG.

16 February 2007 113

SWIFTNet FINCopy

114 Service Description