WSS Swift Connectivity Guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 294

Download
Open PDF In Browser	View PDF

www.wallstreetsystems.com

Wall Street Systems – Empowering Treasury Trade and Settlement

Wallstreet Suite
SWIFT Connectivity Guide
Version 7.3.16

Information in this document is subject to change without notice and does not represent a commitment on the part
of Wall Street Systems. The software and documentation, which includes information contained in any databases,
described in this document is furnished under a license agreement or nondisclosure agreement and may only be
used or copied in accordance with the terms of the agreement. It is against the law to copy the software or
documentation except as specially allowed in the license or nondisclosure agreement. No part of this publication
may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical,
photocopying, recording, or otherwise, without the prior written permission of Wall Street Systems.
Although Wall Street Systems has tested the software and reviewed the documentation, Wall Street Systems
makes herein no warranty or representation, either expressed or implied, with respect to software or
documentation, its quality, performance, marketability, or fitness for a particular purpose. As a result, this
software is provided "as is", and in no event will Wall Street Systems be liable for direct, indirect, special,
incidental, or consequential damages from any defect in the software or by virtue of providing this
documentation, even if advised of the possibility of such damages. The documentation may contain technical
inaccuracies and omissions.
The mention of an activity or instrument in this publication does not imply that all matters relating to that activity or
instrument are supported by Wallstreet Suite, nor does it imply that processing of or by that activity or instrument is
carried out in any particular way, even if such processing is customary in some or all parts of the industry.
The windows and screen images shown herein were obtained from prototypes during software development. The
actual windows and screen images in the software may differ.
© Copyright 2011 Wall Street Systems IPH AB. All rights reserved.
First Edition (August 2011)
This edition applies to Wallstreet Suite version 7.3.16 and to all later releases and versions until indicated in new
editions or Wall Street Systems communications. Make sure you are using the latest edition for the release level of
the Wall Street Systems product.

Wall Street Systems, WSS, WALLSTREET, WALLSTREET SUITE and the Wall Street Systems logos are
trademarks of Wall Street Systems Delaware, Inc.
Finance KIT, Trema and Trema logo are trademarks of Wall Street Systems Sweden AB.
Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
Adobe, Acrobat, and Acrobat Reader are either registered trademarks or trademarks of Adobe Systems
Incorporated in the United States and/or other countries.
All other products mentioned in this book may be trademarks or service marks of their respective companies or
organizations.
Company names, people names, and data used in examples are fictitious unless otherwise noted.

2

Contents

Preface ...........................................................................................................................15
1 Overview ....................................................................................................................17
1.1 Introduction ........................................................................................................................... 17
1.2 SWIFT interface components ............................................................................................... 17
1.2.1 Enterprise Swift Integration Adapter ............................................................................... 18
1.2.2 WebSuite ........................................................................................................................ 18
1.2.3 TRMSwift ........................................................................................................................ 18
1.2.4 FIN messaging components ........................................................................................... 19
1.3 Confirmation matching using SWIFTNet Accord ............................................................... 19

2 ESIAdapter configuration .........................................................................................21
2.1 Introduction ........................................................................................................................... 21
2.1.1 Send ................................................................................................................................ 21
2.1.2 Status .............................................................................................................................. 21
2.1.3 Receive ........................................................................................................................... 22
2.1.4 Polling SWIFTNet Accord ............................................................................................... 22
2.1.5 Message sequencing ...................................................................................................... 22
2.2 Using a service bureau ......................................................................................................... 22
2.3 Installation ............................................................................................................................. 22
2.4 Configuration ......................................................................................................................... 22
2.4.1 Required interfaces ......................................................................................................... 23
2.4.1.1 Incoming Message Routing .................................................................................. 23
2.4.2 Fixed Parameters ............................................................................................................ 23
2.4.2.1 Introduction ........................................................................................................... 23
2.4.2.2 esiadapter.properties ............................................................................................ 24
2.4.2.3 esiadapter-finswift.xml .......................................................................................... 31
2.4.2.4 fileact.properties ................................................................................................... 37
2.4.3 ESIAdapter FINSwift API Rule Editor ............................................................................. 37
2.4.3.1 Introduction ........................................................................................................... 37
2.4.3.2 Usage ................................................................................................................... 38
2.4.4 Esiadapter Module Name Rule Editor ............................................................................. 38
2.4.4.1 Introduction ........................................................................................................... 38
2.4.4.2 Usage ................................................................................................................... 38
2.4.4.3 Fields .................................................................................................................... 39
2.4.5 Additional Connectivity to SWIFT Alliance Access ......................................................... 39
2.4.5.1 Introduction ........................................................................................................... 39

SWIFT Connectivity Guide

3

2.4.5.2 MQHA with MQ-MT .............................................................................................. 39
2.4.5.3 MQHA with XML ................................................................................................... 39
2.4.5.4 SOAP .................................................................................................................... 39
2.4.6 MQSeries and SSL ......................................................................................................... 39
2.4.6.1 Encryption modes ................................................................................................. 40
2.4.6.2 Creating the Java client's certificate ..................................................................... 40
2.4.6.3 SSL setup for ESIAdapter .................................................................................... 41
2.4.6.4 ssl.properties ........................................................................................................ 41
2.4.6.5 Debugging ............................................................................................................ 42
2.4.6.6 credential.properties ............................................................................................. 42
2.5 Environment variables .......................................................................................................... 43
2.6 Statuses ................................................................................................................................. 43
2.7 ESIAdapter Client Relationship Editor ................................................................................ 44
2.7.1 FIN Swift page ................................................................................................................ 44
2.7.2 FileAct page .................................................................................................................... 44
2.7.3 Accord page .................................................................................................................... 46
2.8 RAHA ...................................................................................................................................... 46
2.9 Starting ESIAdapter with Process Monitor ......................................................................... 47
2.9.1 Processes in PMM .......................................................................................................... 47
2.9.2 Assumptions ................................................................................................................... 47
2.9.3 ESIAdapter and PMM configuration procedure .............................................................. 47
2.9.3.1 RAHA .................................................................................................................... 48
2.10 File Simulation Mode .......................................................................................................... 48
2.10.1 FileAct simulation .......................................................................................................... 48
2.10.2 FIN simulation ............................................................................................................... 48
2.10.3 Changing from simulation mode ................................................................................... 49
2.11 ESIAdapter simulator .......................................................................................................... 49
2.11.1 Simulating sending a FIN message .............................................................................. 49
2.11.2 Simulating sending a FileAct message ......................................................................... 49

3 CASmf configuration ................................................................................................51
3.1 Installing CASmf ................................................................................................................... 51
3.2 Configuring CASmf ............................................................................................................... 51
3.2.1 Modifying the dmapid.dat file .......................................................................................... 51
3.2.2 Setting environment variables ......................................................................................... 52
3.3 Configuring SWIFTAlliance .................................................................................................. 52
3.3.1 SWIFTAlliance Security .................................................................................................. 52
3.3.2 Receiving a failure (NACK) from SWIFTAlliance ............................................................ 53
3.3.2.1 NACK received from a transmission or delivery report ......................................... 53
3.4 Configuring TRMSwift .......................................................................................................... 54
3.5 Debugging ............................................................................................................................. 55

4 FIN messaging configuration ...................................................................................57
4.1 FIN messaging components ................................................................................................ 57
4

© Wall Street Systems IPH AB - Confidential

4.1.1 FIN Messaging flow diagram .......................................................................................... 58
4.1.1.1 FINWriter saves the message in the database ..................................................... 59
4.1.1.2 FINsend sends message to adapter ..................................................................... 59
4.1.1.3 TRMSWIFT Receiver receives status for sent messages .................................... 59
4.1.1.4 Receiver receives new messages ........................................................................ 59
4.1.1.5 Responder responds with status updates ............................................................ 59
4.1.1.6 CMM FIN messages monitored on FIN Message Manager ................................. 60
4.2 FIN message administration (TRM) ..................................................................................... 61
4.2.1 Previewing changes to FIN messages ............................................................................ 62
4.2.2 FIN message administration (WebSuite) ........................................................................ 62
4.2.2.1 FIN message label mapping ................................................................................. 65
4.3 FIN Message Rule Editor ...................................................................................................... 65
4.3.1 Rules versus finmessage.py ........................................................................................... 68
4.3.1.1 Straight through processing .................................................................................. 68
4.3.1.2 finmessage.py ...................................................................................................... 68
4.4 FIN Message Action Editor ................................................................................................... 68
4.4.1 Rules ............................................................................................................................... 68
4.4.2 Actions ............................................................................................................................ 69

5 SWIFTnet Accord ......................................................................................................71
5.1 Confirmation matching ......................................................................................................... 71
5.1.1 Accord simulator ............................................................................................................. 71
5.1.2 Polling the Accord API .................................................................................................... 72
5.1.3 Reconciling of results ...................................................................................................... 73
5.1.4 Updating the FIN Message ............................................................................................. 73
5.1.5 Multiple messages .......................................................................................................... 73
5.1.6 Updating the transaction ................................................................................................. 74
5.1.7 Backdated trades and ESIAdapter .................................................................................. 74

6 SWIFT package overview .........................................................................................75
6.1 Data Integration ..................................................................................................................... 75
6.2 SWIFT message scenarios ................................................................................................... 75
6.2.1 Money market and foreign exchange confirmations ....................................................... 76
6.2.2 Payments ........................................................................................................................ 77
6.2.3 Private client confirmation ............................................................................................... 77
6.2.4 Security movements ....................................................................................................... 78
6.2.5 Statement messages ...................................................................................................... 78
6.2.6 Transaction Generation .................................................................................................. 79
6.3 SWIFT message details ........................................................................................................ 79
6.3.1 MT103 - Single Customer Credit Transfer ...................................................................... 79
6.3.2 MT192 - Request for Cancellation .................................................................................. 80
6.3.3 MT200 - Financial Institution Transfer for its Own Account ............................................ 80
6.3.4 MT202 - General Financial Institution Transfer ............................................................... 80
6.3.5 MT203 - Multiple General Financial Institution Transfer ................................................. 80
6.3.6 MT210 - Notice to Receive ............................................................................................. 80

SWIFT Connectivity Guide

5

6.3.7 MT292 - Request for Cancellation .................................................................................. 81
6.3.8 MT300 - Foreign Exchange Confirmation ....................................................................... 81
6.3.9 MT305 - Foreign Currency Option Confirmation ............................................................. 81
6.3.10 MT320 - Fixed Loan/Deposit Confirmation ................................................................... 81
6.3.11 MT330 - Call/Notice Loan/Deposit Confirmation ........................................................... 81
6.3.12 MT340 - Forward Rate Agreement Confirmation .......................................................... 81
6.3.13 MT341 - Forward Rate Agreement Settlement Confirmation ........................................ 82
6.3.14 MT350 - Advice of Loan/Deposit Interest Payment ...................................................... 82
6.3.15 MT362 - Interest Rate Reset/Advice of Payment .......................................................... 82
6.3.16 MT392 - Request for Cancellation ................................................................................ 82
6.3.17 MT395 - Queries ........................................................................................................... 82
6.3.18 MT396 - Answers .......................................................................................................... 82
6.3.19 MT399 - Free Format Messages .................................................................................. 82
6.3.20 MT515 - Client Confirmation of Purchase or Sale ........................................................ 82
6.3.21 MT518 - Market-Side Securities Trade Confirmation .................................................... 83
6.3.22 MT535 Statement of Holdings ...................................................................................... 83
6.3.23 MT540 - Receive Free .................................................................................................. 83
6.3.24 MT541 - Receive Against Payment .............................................................................. 83
6.3.25 MT542 - Deliver Free .................................................................................................... 83
6.3.26 MT543 - Delivery Against Payment .............................................................................. 83
6.3.27 MT592 - Request for Cancellation ................................................................................ 84
6.3.28 MT599 - Free Format Message .................................................................................... 84
6.3.29 MT604 - Precious Metal Transfer/Delivery Order ......................................................... 84
6.3.30 MT692 - Request for Cancellation ................................................................................ 84
6.3.31 MT699 - Free Format Message .................................................................................... 84
6.3.32 MT900 - Confirmation of Debit ...................................................................................... 84
6.3.33 MT910 - Confirmation of Credit ..................................................................................... 84
6.3.34 MT950 - Statement Message ........................................................................................ 84
6.3.35 MT992 - Request for Cancellation ................................................................................ 85

7 SWIFT package configuration ..................................................................................87
7.1 Configuring swift.properties ................................................................................................ 87
7.1.1 MT515 ............................................................................................................................. 87
7.2 Pre-defined confirmation adapters ...................................................................................... 87
7.2.1 FXConfirmation ............................................................................................................... 88
7.2.2 MMConfirmation .............................................................................................................. 88
7.2.3 BAConfirmation ............................................................................................................... 88
7.2.4 FixingConfirmation .......................................................................................................... 88
7.2.5 CancelConfirmation ........................................................................................................ 89
7.2.6 Payments ........................................................................................................................ 89
7.3 Instrument groups ................................................................................................................ 89

8 TRMSwift and CMM setup after installation ...........................................................91
8.1 Introduction ........................................................................................................................... 91
8.2 Setting up TRMSwift environment variables ...................................................................... 91
8.3 Updating tables ..................................................................................................................... 91
6

© Wall Street Systems IPH AB - Confidential

8.3.1 Visualizing the configuration ........................................................................................... 91
8.4 Setting up the CMM environment ........................................................................................ 92
8.4.1 Technical setup ............................................................................................................... 92
8.4.2 Communication protocol and interchange setup ............................................................. 93
8.4.2.1 Communication protocol for FIN ........................................................................... 93
8.4.2.2 Communication protocol for FileAct ...................................................................... 94
8.4.2.3 Interchange setup ............................................................................................... 100
8.5 Starting WSS processes ..................................................................................................... 103
8.6 Renaming TRMSwift tables ................................................................................................ 103
8.7 Windows services ............................................................................................................... 103
8.7.1 Using Process Monitor .................................................................................................. 103
8.7.2 Using the Wrapper tool ................................................................................................. 103

9 TRMSwift environment setup ................................................................................105
9.1 Accessing the database ..................................................................................................... 105
9.2 TRMSwift XML tag structure .............................................................................................. 105
9.2.1 Editing XML files ........................................................................................................... 105
9.2.2  .................................................................................................................. 106
9.2.2.1  .............................................................................................................. 106
9.2.2.2  ................................................................................................................. 107
9.2.2.3  ............................................................................................................. 107
9.2.2.4  .................................................................................................. 107
9.3 Setting environment variables ........................................................................................... 108
9.4 Setting package properties ................................................................................................ 109
9.4.1 Feeder ........................................................................................................................... 110
9.4.2 Printer ........................................................................................................................... 111
9.4.3 Email ............................................................................................................................. 111
9.5 Setting SWIFT properties ................................................................................................... 111
9.5.1 CASmf .......................................................................................................................... 112
9.5.2 SWIFT header .............................................................................................................. 112
9.5.3 MT515 ........................................................................................................................... 112
9.6 Setting TRMSwift properties .............................................................................................. 113
9.6.1 Ports .............................................................................................................................. 113
9.6.2 Static data refresh and TRMSwift-comKIT communication .......................................... 113
9.7 Setting up TRM .................................................................................................................... 113
9.7.1 Configuring the transaction flow .................................................................................... 114
9.7.1.1 Getting the data .................................................................................................. 114
9.7.1.2 Success or failure ............................................................................................... 115
9.7.1.3 Modes ................................................................................................................. 115
9.7.1.4 Cancelling transactions ...................................................................................... 115
9.7.1.5 Creating transaction rules ................................................................................... 115
9.7.2 Configuring the payment flow ....................................................................................... 115
9.7.2.1 Creating settlement transfer methods and rules ................................................. 116

SWIFT Connectivity Guide

7

10 TRMSwift security and permissions setup .........................................................117
10.1 Guaranteeing security across the network .................................................................... 117
10.1.1 Implementing encryption over the network ................................................................. 117
10.1.2 Identifying network objects .......................................................................................... 117
10.1.3 File system security .................................................................................................... 118
10.2 Audit Manager ................................................................................................................... 118
10.3 TRMSwift data workflow ................................................................................................... 118
10.3.1 Verifying messages ..................................................................................................... 118
10.4 Database security ............................................................................................................. 119
10.4.1 Identification and authentication ................................................................................. 119
10.4.1.1 Logging into TRMSwift ..................................................................................... 119
10.4.1.2 Entering passwords .......................................................................................... 119
10.4.2 Division of roles in TRMSwift ...................................................................................... 119
10.4.2.1 Privileged user "trmswift" .................................................................................. 120
10.4.2.2 Defining non-privileged users ........................................................................... 120

11 TRMSwift routine maintenance ...........................................................................121
11.1 Overview ............................................................................................................................ 121
11.2 Scheduling actions ........................................................................................................... 121
11.3 Displaying the current TRMSwift configuration ............................................................. 123

12 TRMSwift message configuration .......................................................................125
12.1 Creating a new message .................................................................................................. 125
12.1.1 Obtaining data ............................................................................................................. 125
12.1.1.1 Modifying an existing adapter ........................................................................... 125
12.1.1.2 Creating a new adapter .................................................................................... 125
12.1.2 Understanding data ..................................................................................................... 125
12.1.3 Deciding on message(s) ............................................................................................. 126
12.1.4 Verifying the message(s) ............................................................................................ 126
12.1.4.1 Setting up the workflow .................................................................................... 126
12.1.4.2 Previewing the messages ................................................................................. 126
12.1.4.3 Adding columns to the Message Monitor ......................................................... 126
12.1.5 Formatting the message(s) ......................................................................................... 126
12.1.6 Sending the message(s) ............................................................................................. 127
12.1.7 Notifying TRM of success or failure ............................................................................ 127
12.2 Configuring existing messages ....................................................................................... 127
12.2.1 Adding a new field to a message ................................................................................ 127
12.2.2 Changing a value ........................................................................................................ 127
12.2.3 Removing a value ....................................................................................................... 128
12.3 Constructed XML .............................................................................................................. 128
12.3.1 Business event ............................................................................................................ 128
12.3.1.1 Administrative data ........................................................................................... 128
12.3.1.2 Keys and values ............................................................................................... 130
12.3.1.3 Original data received from the adapter ........................................................... 130

8

© Wall Street Systems IPH AB - Confidential

12.3.1.4 Relationship to other business events .............................................................. 131
12.3.1.5 Related messages ............................................................................................ 131
12.3.2 Message ..................................................................................................................... 132
12.3.2.1 Administrative data ........................................................................................... 132
12.3.2.2 Keys and values ............................................................................................... 133
12.3.2.3 Message failure received from CASmf ............................................................. 134
12.3.2.4 Original data of the message ............................................................................ 134
12.3.2.5 Sequence data ................................................................................................. 134
12.4 Rules .................................................................................................................................. 135
12.4.1 XPath expressions ...................................................................................................... 135
12.4.2 XPath rules ................................................................................................................. 135
12.5 Actions ............................................................................................................................... 137
12.5.1 Encoder actions .......................................................................................................... 137
12.5.2 Multiple actions ........................................................................................................... 138
12.5.2.1 Template lists ................................................................................................... 138
12.5.2.2 XSLT actions .................................................................................................... 139
12.5.2.3 Fixed result actions ........................................................................................... 139
12.5.2.4 Template list hooks ........................................................................................... 140
12.5.3 Template list example ................................................................................................. 140
12.5.4 Working with rules and actions ................................................................................... 143
12.5.5 SWIFT Tagifyer ........................................................................................................... 144

13 TRMSwift workflow configuration .......................................................................147
13.1 Using flags within the workflow ...................................................................................... 147
13.1.1 Defining your own flags ............................................................................................... 147
13.1.2 Applying flags to a business event or message .......................................................... 148
13.1.3 Checking the flags of a business event or message ................................................... 149
13.2 Configuring the workflow ................................................................................................. 149
13.2.1 Defining workflow elements ........................................................................................ 150
13.2.2 Defining workflow deciders ......................................................................................... 152
13.2.3 Defining each of the workflow elements ..................................................................... 153
13.2.3.1 Inbound Message Handler ............................................................................... 153
13.2.3.2 BusinessEventSplitter ....................................................................................... 157
13.2.3.3 Waiter ............................................................................................................... 159
13.2.3.4 OutboundMessageHandler ............................................................................... 161
13.2.3.5 Reconciliator ..................................................................................................... 164
13.2.3.6 BusinessEventNotifyer ..................................................................................... 166
13.2.3.7 KeyLoader ........................................................................................................ 167
13.2.3.8 Message Merger ............................................................................................... 170
13.2.3.9 Relationship Maker ........................................................................................... 174
13.3 Connection Pooling .......................................................................................................... 176

14 TRMSwift adapter configuration ..........................................................................179
14.1 Processes .......................................................................................................................... 179
14.2 Defining an adapter ........................................................................................................... 179

SWIFT Connectivity Guide

9

14.2.1 Configuration ............................................................................................................... 180
14.2.1.1 Feeder resource specification .......................................................................... 180
14.2.1.2 Connector specification .................................................................................... 181
14.2.1.3 Filter specification ............................................................................................. 181
14.2.1.4 Joiner specification ........................................................................................... 182
14.2.1.5 Feeder component instance ............................................................................. 183
14.3 Implemented connectors .................................................................................................. 184
14.3.1 Incoming SWIFT messages connector ....................................................................... 185
14.3.2 comKIT connector factory ........................................................................................... 185
14.3.2.1 Transaction connector ...................................................................................... 186
14.3.2.2 Data connector ................................................................................................. 192
14.3.2.3 Static Data connector ....................................................................................... 193
14.3.2.4 Parameters ....................................................................................................... 196
14.3.3 Settlement queue factory ............................................................................................ 197
14.3.4 Queue adapter TBA .................................................................................................... 199
14.3.5 SQL connector factory ................................................................................................ 199
14.3.5.1 Parameters ....................................................................................................... 200
14.3.6 Internet connector factory ........................................................................................... 202
14.3.6.1 Email connector ................................................................................................ 202
14.3.6.2 TCP/IP connector ............................................................................................. 205
14.3.7 Printer connector factory ............................................................................................. 206
14.3.7.1 Parameters ....................................................................................................... 206
14.3.8 File connector factory .................................................................................................. 206
14.3.8.1 Parameters ....................................................................................................... 206
14.3.9 FIX connector factory .................................................................................................. 208
14.3.9.1 Parameters ....................................................................................................... 208
14.3.10 HTTP connector factory ............................................................................................ 208
14.3.10.1 Parameters ..................................................................................................... 208
14.3.11 Tomcat connector factory ......................................................................................... 210
14.3.11.1 TomcatConnectorIn connector ....................................................................... 210
14.3.11.2 Parameters ..................................................................................................... 210
14.3.11.3 TomcatConnectorOut connector .................................................................... 210
14.3.11.4 Parameters ..................................................................................................... 210
14.3.12 MQSeries connector factory ..................................................................................... 211
14.3.12.1 Message delivery ............................................................................................ 211
14.3.12.2 Parameters ..................................................................................................... 212
14.3.12.3 MQ descriptor: FORMAT parameter ............................................................... 214
14.3.13 JMS connector factory .............................................................................................. 214
14.3.13.1 Parameters ..................................................................................................... 214

15 TRMSwift monitor configuration .........................................................................217
15.1 Starting the user interfaces with TRM variables ............................................................ 217
15.2 Configuring the trusted connection ................................................................................ 217
15.3 Setting the user interface permissions ........................................................................... 217
15.4 Configuring System Monitor ............................................................................................ 217
15.4.1 Columns ...................................................................................................................... 218

10

© Wall Street Systems IPH AB - Confidential

15.4.1.1 Defining system components ........................................................................... 219
15.4.1.2 Defining a Log event ......................................................................................... 220
15.5 Configuring Message Monitor ......................................................................................... 221
15.5.1 General layout and default values .............................................................................. 221
15.5.2 Previewers .................................................................................................................. 223
15.5.3 Columns ...................................................................................................................... 224
15.5.4 Modes and actions ...................................................................................................... 227
15.5.5 Modes and Permissions .............................................................................................. 230
15.5.6 Filter Editor .................................................................................................................. 231

16 TRMSwift debugging ............................................................................................233
16.1 Using System Monitor ...................................................................................................... 233
16.1.1 Accessing TRMSwift System Monitor ......................................................................... 233
16.1.2 The System Monitor window ....................................................................................... 234
16.1.3 Using the System Component tab .............................................................................. 234
16.1.4 Viewing the Workflow Log ........................................................................................... 235
16.1.5 Viewing the System Log ............................................................................................. 236
16.1.6 Viewing the Error Log ................................................................................................. 237
16.1.7 Entering search criteria in the log panels .................................................................... 238
16.2 Triggering actions ............................................................................................................. 238
16.3 Toolbar menu items .......................................................................................................... 238
16.3.1 File menu .................................................................................................................... 238
16.3.2 View menu .................................................................................................................. 238
16.3.3 Filter menu .................................................................................................................. 239
16.3.4 Command menu ......................................................................................................... 239
16.3.5 Action menu ................................................................................................................ 239
16.3.6 Help menu ................................................................................................................... 239
16.4 Logging components ........................................................................................................ 240
16.4.1 Log files ....................................................................................................................... 240
16.4.1.1 FileAct logging at startup .................................................................................. 242
16.4.2 Logging manipulated data ........................................................................................... 243
16.4.3 TRMSwift event logs ................................................................................................... 243
16.5 Obtaining the full XML of a business event or message ............................................... 243
16.6 Performing actions on Workflow Elements or the Encoder ......................................... 243
16.7 Inbound Message Handler ............................................................................................... 244
16.8 Plain XML tools ................................................................................................................. 244
16.9 Validating custom transformation scripts ...................................................................... 244
16.10 TestFeeder ....................................................................................................................... 244
16.11 Troubleshooting .............................................................................................................. 246

17 TRMSwift Message Monitor .................................................................................249
17.1 Accessing TRMSwift Message Monitor .......................................................................... 249
17.2 The Message Monitor window ......................................................................................... 250

SWIFT Connectivity Guide

11

17.2.1 Toolbar ........................................................................................................................ 250
17.2.2 Message panel ............................................................................................................ 251
17.2.3 Preview panel ............................................................................................................. 251
17.2.3.1 Text previewer .................................................................................................. 252
17.2.3.2 Tree previewer .................................................................................................. 253
17.2.3.3 XML previewer .................................................................................................. 254
17.2.3.4 Fax previewer ................................................................................................... 255
17.2.4 Related and Sequence panel ...................................................................................... 255
17.2.4.1 Related tab ....................................................................................................... 255
17.2.4.2 Sequence tab ................................................................................................... 256
17.3 Using Filter Editor ............................................................................................................. 256
17.3.1 Keys panel .................................................................................................................. 257
17.3.2 Flags panel ................................................................................................................. 259
17.3.2.1 Flags ................................................................................................................. 259
17.4 Toolbar menu items .......................................................................................................... 260
17.4.1 File menu .................................................................................................................... 260
17.4.2 Edit menu .................................................................................................................... 260
17.4.3 View menu .................................................................................................................. 260
17.4.4 Mode menu ................................................................................................................. 260
17.4.5 Command menu ......................................................................................................... 261
17.4.6 Filter menu .................................................................................................................. 262
17.4.7 Option menu ............................................................................................................... 262
17.4.8 Update menu .............................................................................................................. 263
17.4.9 Help menu ................................................................................................................... 263

18 ESIAdapter File Interface ......................................................................................265
18.1 Introduction ....................................................................................................................... 265
18.2 Requirements and features .............................................................................................. 265
18.3 How it works ...................................................................................................................... 267
18.3.1 Startup ........................................................................................................................ 267
18.3.2 Processing .................................................................................................................. 267
18.3.3 Recovery and errors ................................................................................................... 268
18.3.4 Logging ....................................................................................................................... 268
18.4 Configuration ................................................................................................................... 268
18.4.1 Bank connection configuration .................................................................................... 268

Appendix A: Properties files .................................................................................................271
A.1 environment.properties ..................................................................................................... 271
A.2 jms.properties ..................................................................................................................... 271
A.3 oracle.properties ................................................................................................................ 271
A.3.1 General properties ........................................................................................................ 272
A.3.2 Hibernate properties ..................................................................................................... 272

Appendix B: Time zones........................................................................................................275

12

© Wall Street Systems IPH AB - Confidential

Appendix C: Configuration data ...........................................................................................279
C.1 Configuration ...................................................................................................................... 279
C.1.1 Setup ............................................................................................................................ 279
C.1.2 Actions .......................................................................................................................... 279
C.1.3 Rules ............................................................................................................................ 280
C.2 Permissioning ..................................................................................................................... 281
C.3 Logs ..................................................................................................................................... 281
C.3.1 Workflow log ................................................................................................................. 281
C.3.2 System log .................................................................................................................... 282
C.3.3 Error log ........................................................................................................................ 282
C.4 Business data ..................................................................................................................... 282
C.4.1 State elements (business events and messages) ........................................................ 283
C.4.2 Element sequences ...................................................................................................... 284
C.4.3 Search keys .................................................................................................................. 284
C.4.4 Specification ................................................................................................................. 285
C.4.5 State element timeout (for waiters) .............................................................................. 285
C.4.6 State element eyes (for 4-eyes verification) ................................................................. 286
C.4.7 Delivery element ........................................................................................................... 286
C.4.8 Counter element ........................................................................................................... 287
C.4.9 Safe store ..................................................................................................................... 288
C.5 Entity Diagram .................................................................................................................... 289

Appendix D: Connecting to TRM components....................................................................291
D.1 Running comKIT services ................................................................................................. 291
D.2 Using ActiveMQ and Serviced ........................................................................................... 291

Appendix E: Reading passwords from memory .................................................................293
E.1 Using Shared Memory ........................................................................................................ 293
E.1.1 UNIX ............................................................................................................................. 293
E.1.2 Windows ....................................................................................................................... 293
E.2 Starting processes without entering a password ............................................................ 293

SWIFT Connectivity Guide

13

14

© Wall Street Systems IPH AB - Confidential

Preface

This guide describes how Wallstreet Suite uses SWIFT. It includes information on how to configure
TRM and WebSuite to meet your business needs. For convenience, it includes information on system
administration.
This guide is intended for Wallstreet Suite system administrators and developers. You should have
an good knowledge of XML, XSL configuration, and the UNIX environment. A good knowledge of
TRM, transaction processing, and cash management is also essential. You should also have
experience with databases and SQL.

Terminology
CMM refers to the Cash Management Module of WebSuite.

Associated documents
•

TRM User Guide

•

TRM System Administration Guide

•

WebSuite Cash Management Connectivity Guide

•

Wallstreet Suite System Administration Guide

SWIFT Connectivity Guide

15

16

© Wall Street Systems IPH AB - Confidential

Chapter 1

Overview

1.1 Introduction
TRM and CMM (the Cash Management part of WebSuite) can both interface with the SWIFT network,
using SWIFT’s FIN, FileAct, and InterAct SWIFT protocols.

SWIFT

FIN

TRM

WebSuite
(Cash Management)

FileAct

InterAct

WebSuite
(Cash Management)

Accord
(TRM and FIN)

FIN
FIN is SWIFT's core store-and-forward messaging service that enables financial institutions to
exchange financial data securely.

FileAct
FileAct allows secure and reliable transfer of files and is typically used to exchange batches of
structured financial messages and large reports.

InterAct
InterAct is SWIFT's interactive messaging service supporting the exchange of messages between
two parties. It enables the Accord matching application (see below).

Accord
Accord is a fail-safe matching and exception handling solution for foreign exchange, money market
and OTC derivative confirmations.

Note: For more information about SWIFT services, go to http://www.swift.com.

1.2 SWIFT interface components
The relationship between the SWIFT interface components is shown here:
These components are described briefly in this chapter, and in details of configuration are given in
later chapters.

SWIFT Connectivity Guide

17

SWIFT interface components

1.2.1 Enterprise Swift Integration Adapter
The Enterprise Swift Integration Adapter (ESIAdapter) is responsible for communicating with various
SWIFT applications. It is made up of four parts that are responsible for:

•

Sending messages to SWIFT

•

Providing status updates coming from SWIFT

•

Providing new incoming messages received from SWIFT

•

Polling SWIFTNet Accord for getting matching status updates.

1.2.2 WebSuite
WebSuite is a fully web-enabled software application that allows you to deploy optimal centralized or
decentralized treasury and cash management. Its Cash Management Module uses SWIFT
messaging. Technical details are provided in the WebSuite Cash Management Connectivity Guide.

1.2.3 TRMSwift
TRMSwift is a stand-alone module that can interface with TRM, or any other compatible financial
application, by means of its plug-and-play architecture. Asset managers, corporates, banks and
central banks can use TRMSwift to connect internal financial applications to exchange messages with
external systems such as SWIFTAlliance, electronic mail systems, fax, FIX engine or telex.
TRMSwift sends notification and instruction messages across a communications network. It provides
a gateway to thousands of SWIFT members through a fast, highly reliable, and secure network.
Increasingly, non-banking organizations are taking advantage of SWIFT, which is widely used in the
banking community.
TRMSwift enables two-way, real-time communication between financial applications and payment
networks. It provides a highly customizable framework that supports multi-network connections,
and is compatible with your in-house applications or third-party systems through the use of
dedicated components.
You can modify TRMSwift’s configuration to meet changing business needs. An TRMSwift message
can be any message that is assembled and formatted using rules defined within the TRMSwift
environment. The message can then be delivered to its recipient through an TRMSwift delivery
channel.
With TRMSwift you can:

•

Transfer and confirm messages between integrated systems.

•

Control the content of messages sent to counterparties following a business action or set of
actions.

•

Configure message generation and define additional delivery channels.

•

Offer a secure and reliable interface to external systems.

•

Manage and monitor fallback processes generated upon error handling, failure notification, retry
and abort operations.

TRMSwift supports the SWIFT, Fax, SQL, FIX, e-mail, printer, file- or socket-based delivery channels
and includes documentation to help implement other channels.
TRMSwift is capable of handling the automatic flow of business events between systems across the
organization without any manual intervention. This is achieved through a seamless information flow
that does not affect the operation of the systems connected to TRMSwift.
Interoperability is ensured by TRMSwift’s ability to:

•

Process different data formats and transaction formats.

•

Handle exception conditions without impacting the business.

•

Audit and report on relevant events.

18

© Wall Street Systems IPH AB - Confidential

Confirmation matching using SWIFTNet Accord

TRMSwift supports various packages. Each of these packages includes the business logic and
template messages required for connecting the respective applications. They include:

•

SWIFT message templates

•

Order Management Module for connectivity to brokers via a FIX engine

•

Fax message templates for confirmation of collateralized transactions

•

Confirmation matching using CityNet Matching

•

Cash Management Module integration.

1.2.4 FIN messaging components
The components between TRMSwift and ESIAdapter are responsible for updating the FINMessage
Manager, as well as for facilitating communication with TRMSwift and ESIAdapter. These
components are not apparent to users.
Use of the components is driven by the FINMessage flow, either because they are triggered from
there (e.g. sending a message or responding to TRMSwift with a status update) or because they
trigger the flow (e.g. receiving a new message to send, receiving a new message that has been
received or receiving a status update from ESIAdapter about a message that has been received).

1.3 Confirmation matching using SWIFTNet Accord
SWIFTNet Accord is a service provided by SWIFT (on the SWIFT network), where messages are
copied to the Accord service for any business entity that subscribes to the service. SWIFTNet Accord
then either performs the confirmation matching automatically, or allows users to perform manual
matching. TRM retrieves the matching status from Accord and updates itself with the relevant
information.

SWIFT Connectivity Guide

19

Confirmation matching using SWIFTNet Accord

20

© Wall Street Systems IPH AB - Confidential

Chapter 2

ESIAdapter configuration

2.1 Introduction
The Enterprise Swift Integration Adapter (ESIAdapter) is the common component that is shared by
TRM (via TRMSwift) and CMM. It is responsible for sending FIN, FileAct and InterAct messages to the
SWIFT network or receiving messages from the SWIFT network.
ESIAdapter is responsible for communicating with various SWIFT applications. It is made up of four
parts that are responsible for:

•

Sending messages to SWIFT

•

Providing status updates coming from SWIFT

•

Providing new incoming messages received from SWIFT

•

Polling SWIFTNet Accord for getting matching status updates.

How communication occurs with the SWIFT application depends on the application, as well as the
type of the message (FIN, FileAct, or InterAct). Communication can be via File, MQSeries, RAHA or
CASmf. It contains the components described in this section (See 4.1.1 FIN Messaging flow diagram
on page 58 for references to queue numbers).

2.1.1 Send
The Send component receives FIN or FileAct messages from TRM (FIN) or CMM and passes them
either to SWIFTAlliance Access (SAA) or to SWIFTAlliance Gateway (SAG). These message types are
received on a queue (Q09) from either TRMSwiftFINSend or CMM, processed, and then sent to the
relevant SWIFT application (Q07 or Q10). Data is fetched from the ESIAdapter Client Relationship
Editor to find out things like which type of compression to use, or which test BIC code to use.
The component also performs some basic validation, such as check that a sender and receiver have
been provided. If the validation fails, an immediate failure reply is generated.

2.1.2 Status
After an initial message has been sent, the Status component receives various statuses back from
the SWIFT application. Each of these statuses is provided back to the originating application (either
TRMSwiftFINReceive or CMM) with an indication of success, failure or time-out, a final indicator
which indicates that no more updates are expected, and an error message if relevant. The following
statuses are supported.

•

API: The Send component was able to validate the basic information and pass the message to
the SWIFT application's interface (either CASmf or MQSeries, or save it to a file). This status is
the immediate status that is returned by the send component (see above)

•

SEND: The message was able to be sent to the SWIFT application and that it has received it.

•

TRANSFER: ACK or NACK has been received (FIN only; does not exist for FileAct).

•

DELIVERY: The final delivery notification has been received back from the SWIFT counterparty.

Each of these statuses is updated in the originating application.

SWIFT Connectivity Guide

21

Using a service bureau

2.1.3 Receive
The Receive component is responsible for passing messages (including FIN, FileAct) to either
TRMSwift (FINReceive) or CMM. The destination is based on configuration within ESIAdapter,
typically based on the message type and whether either TRM or CMM is installed standalone.
ESIAdapter performs no processing on FIN messages. On FileAct messages it performs unzipping if
required.

2.1.4 Polling SWIFTNet Accord
Polling of SWIFTNet Accord is done directly in ESIAdapter and the polling interval can be configured.
When status updates are received back after such a poll, they are passed to the confirmation
matching components for further processing. See 5.1 Confirmation matching on page 71 for more
details.

2.1.5 Message sequencing
A SWIFT MT535, MT940 or MT950 message can be broken up into multiple messages by the SWIFT
network because of SWIFT restrictions on the maximum message size. If this happens, these
messages can arrive out of sequence.
ESIAdapter assembles in sequence all MT940 messages to do with a particular bank statement into
a single FIN message which it passes to CMM.
ESIAdapter resequences MT950 or MT535 messages to do with a particular bank statement so that
TRMSwift receives the parts in the correct order.

2.2 Using a service bureau
You may wish to use a Service Bureau for your connection to SWIFT. Service bureaus mainly
support FTP/SFTP as a communication mechanism, and ESIAdapter supports this.

2.3 Installation
ESIAdapter is an Onyx service, and is installed as part of TRM. For more information about Onyx,
see the WSS System Administration Guide.
RAHA must be installed on the same computer that the Onyx service running ESIAdapter is to be
installed on. The installation assumes that you have a licensing agreement with SWIFT and should
be installed using the instructions from SWIFT. The TRM client must be installed before configuring
ESIAdapter.

2.4 Configuration
There are three aspects to consider in the configuration of ESIAdapter:

•

Interfaces required for the particular site

•

Fixed parameters needed by the interfaces

•

Counterpart-specific parameters.

22

© Wall Street Systems IPH AB - Confidential

Configuration

2.4.1 Required interfaces
There are three interfaces currently available, FIN messages via SAA (FIN), Fileact via SAG (Fileact)
and Accord via SAG (Accord).
Normally a banking client requires FIN and maybe Accord, and a corporate requires all three
interfaces. The interfaces are predefined and the one to use is determined by the environment
variable MODULES_ESIADAPTER_SYSTEM. Possible values are:
all

FIN, Fileact and Accord

fin-fileact

FIN and Fileact

fin-match

FIN and Accord

saa

FIN

file

A file-based setup for both FIN and Fileact. This should only be used when the File
Transfer module of SAG is being used.

The default is all. Normally file would not be used as now the actual interface to deliver via is
specified in esiadapter.properties, see the properties:

•

esiadapter.fileact.api

•

esiadapter.interact.api

The environment variable MODULES_ESIADAPTER_SYSTEM is declared in the file 15_esiadapter.bat
which also contains variables that point to the location where RAHA is installed. See 2.9.3
ESIAdapter and PMM configuration procedure on page 47 for details.

Important: You should set the value of MODULES_ESIADAPTER_SYSTEM only in the file
15_esiadapter.bat and not in onyx.bat.

2.4.1.1 Incoming Message Routing
Depending on the value of the environment variable MODULES_ESIADAPTER_SYSTEM, incoming
messages (with data not status) are routed to either the TRM or CMM queues.

•

all and fin-fileact will route FileAct and FIN 100 and 200 and 940/2 messages to CMM.

•

fin-match and saa will route all FIN messages to TRM.

•

Match messages are always routed to the match queue.

This behavior can be overridden by the setting one of the following properties in
esiadapter.properties:

•

esiadapter.destination.cmm

•

esiadapter.destination.trm

2.4.2 Fixed Parameters
2.4.2.1 Introduction
The fixed parameters are included with the Onyx installation in the etc/onyx/properties directory.
The parameters are in the file esiadapter.properties except for the MQSeries FIN interface
parameters, which are in esiadapter.finswift.xml in the same directory.

Note: Database connectivity and passwords may also need to be addressed in some of the other
files in the same directory.

SWIFT Connectivity Guide

23

Configuration

2.4.2.2 esiadapter.properties
Depending on which interfaces are being used, some information in this file may be redundant, but
it must be left in the file as the configuration procedure requires that all values are set, even when
not used.

2.4.2.2.1 Naming Convention
All parameters are named as esiadapter.interface.key. The esiadapter part unambiguously
defines the parameter for ESIAdapter. The interface is a mnemonic that indicates a common part
of the setup that the parameter is used for. The key is an interface-specific identifier. Note that the
interfaces can be low level or high level. The available interface identifiers are:
accord

Information pertaining to the Accord interface.

cleanup

Global information.

destination

Information about the API activemq queues.

environment

Global information about the whole setup.

famq

Information for the MQSeries fileact transport interface.

famqfile

Information for the MQSeries fileact file transfer transport interface.

fileact

Information that is associated with the high level message interface for fileact.

fileactfile

Information associated with the file interface for fileact.

fileactmq

Information needed for the fileact interface using mqseries.

fincas

Information for the CASmf interface for FIN messages.

finfile

Information for the basic file interface for writing FIN messages.

finmq

Information for the MQSeries interface for FIN messages.

finswift

Information for the FIN interface.

iamq

Information about the transport interact interface using MQSeries.

interact

Generic interact information. Note this is currently only used with Accord.

mq.clientchannel

Global information for MQSeries.

sag

Information that is associated with SAG.

2.4.2.2.2 Parameter descriptions
esiadapter.accord.backdays
How far back in time to look for Accord confirmation information. Expressed as a positive number of
days. On a test system, this value might be considerably more than on the production system.

esiadapter.accord.bic
Specifies for which BIC code in the ESIAdapter Client Relationship Editor to run Accord.
Use a BIC code that has been specified in the Editor and that has the Accord page filled in.

esiadapter.accord.timeout
The time between pools for additional matching status items from the accord server. The value is set
in seconds.

24

© Wall Street Systems IPH AB - Confidential

Configuration

esiadapter.cleanup.days
Specifies the number of days during which the history of a message should be stored in the
database.
Integer field representing the number of days. Special values are 0 (zero) and -1.
0 = not to be deleted.
-1 = never stored.

esiadapter.environment
Specifies whether this is a test environment or a production environment.
test environment: true
production environment: false
You should not change this value.

esiadapter.cachedir
Specifies a top level directory for persistence caching (ESIAdapter uses the file system to cache
ongoing processing in the event of a database failure for example). Normally this is below the same
starting point of directories used by ESIAdapter. Note that normally this is the starting point for all
caching directories. The value itself is not used anywhere except to specify the starting point.
All caching directories are created on startup if they do not already exist.

esiadapter.cachedir.bus
Specifies the cache directory used for ActiveMQ message persistence. The default is
${esiadapter.cachedir}/bus.
This directory contains multiple subdirectories that are used for queues.

esiadapter.cachedir.db
Specifies the subdirectory for caching database updates.
The default is ${esiadapter.cachedir}/db.

esiadapter.cachedir.api
Specifies the subdirectory for caching actions for a particular API. For example, FileAct or SWIFT
FIN.
The default is ${esiadapter.cachedir}/api.

esiadapter.cachedir.plugins
Specifies the directory for caching sequenced messages, for example MT940.
The default is ${esiadapter.cachedir}/plugins.

esiadapter.alliance.is-version7
specifies which version of SWIFT Alliance you are using.
Version 7: true, otherwise false.

esiadapter.finswift.logical-terminal
The value to use for the ninth character in the sender's BIC code in block one of the FIN message. In
pilot and test systems this is X; in a normal production system it is X; but for production system end
to end connectivity verification it is A.

SWIFT Connectivity Guide

25

Configuration

esiadapter.finswift.api-list
The list of FIN message interfaces that need to be available. The list is colon (:) separated and the
names in the list must correspond to names specified in esiadapter.finswift.xml. There must
also be an entry in the ESIAdapter FINSwift Rules Editor for the interface, see 2.4.3 ESIAdapter
FINSwift API Rule Editor on page 37.

esiadapter.sag.security.context
The distinguished name associated with the user that can log into SAG.
Use a correctly formatted distinguished name, for example cn=pascal,o=ptsggbee,o=swift
The SAG system administrator decides this.
If strict mode is used (esiadapter.rahaapi.strict=true) then this value will be determined
internally from the user and password information and can be unset. If a value is supplied in this
situation, it will be replaced.

esiadapter.fileactfile.topdirectory
Specifies the top level directory where FileAct files are located. FileAct needs one directory for
outgoing files and one for incoming.
Use the absolute path directory in Unix format. Example: /tmp/fileact
The directory must exist. This ensures that the correct directory is used.

esiadapter.fileactfile.pickupdirectory
When performing FileAct transfers using the FTP mode in SAG, this is the top-level directory in which
to look for files. The directory of the sender/receiver needs to be created below this directory, and
the SAG File Transfer setup should place the incoming file in this directory. Example: /tmp/sag
To use this interface requires access to a file system on the SAG server.

esiadapter.rahasimulatorapi.dir
Specifies the directory for using the RAHA Simulator for FileAct messages.

esiadapter.fileact.system
The system where the FileAct files are being sent; either via Swift Alliance Access (value is saa) or
Swift Alliance Gateway (value is sag).

esiadapter.fileact.drop-subdirectory
Specifies the relative path of the directory for where FileAct files are stored for transfer to SAG.
The absolute path is generated using the value for esiadapter.fileactfile.topdirectory and
this relative path. The directory must exist.

esiadapter.fileact.suffix
Specifies the file ending for non-compressed files. For compressed files, the ending is normally the
name of the compression used.
Use a suffix that complies with operating system naming conventions.
This property is not relevant to ESIAdapter itself, but exists for the benefit of ESIAdapter’s
environment.

esiadapter.fileact.check-transfer
A flag to indicate that the control of the starting of the swfa_handler process is either under the
control of ESIAdapter or is started and controlled externally. It has an effect only if RAHA is being
used for FileAct transfers.

26

© Wall Street Systems IPH AB - Confidential

Configuration

esiadapter.fileact.service
The service name used for FileAct requests. The security and access must be available to the user.
For FileAct real-time the service name is swift.generic.fa

esiadapter.fileact.environment
To specify if the environment is production, training, or testing.
Production: empty
Test and Training: !p
Integrated Test Bed: !x

esiadapter.fileact.username
The default value is the RAHA connection user name.

esiadapter.fileact.password
The default value is the RAHA connection user password (encrypted).

esiadapter.fileact.instance
The name of the message partner in SWIFT Alliance Gateway.

esiadapter.fileact.timeout
How long until RAHA disconnects. Expressed in milliseconds.

esiadapter.fileact.security.context
esiadapter.fileact.strict
Specifies if the SAG interface for FileAct is set up to be strict (true) or relaxed (false).

esiadapter.fileact.file
The name of the service to use for the file transfer part of Fileact. Allowed values are:

•

esiadapterFileactFileFileLowLevel when using RAHA or file-based RAHA simulator.

•

esiadapterFileactMQFileLowLevel when using MQSeries.

•

esiadapterChannelFileactMQFileLowLevel when using MQSeries with a channel definition file.

esiadapter.fileact.api
The name of the API to use for the FileAct request/response messages. This enables using the same
setup for everything by the communication medium. Allowed values are:
esiadapterFAFileLowLevel
Uses a file based simulation of RAHA. this is useful for the initial setup and testing of all components
independent of SWIFT and counterparties.
esiadapterFARahaLowLevel
RAHA interface connecting via SAG/Swift network to counterparties.

esiadapter.famq.hostname
The resolvable hostname or IP address of the MQSeries Server for FileAct connectivity.

esiadapter.famq.port
The port to use on the MQSeries server machine. This equates to the port number for the listener of
the named queue manager.

SWIFT Connectivity Guide

27

Configuration

esiadapter.famq.queue-manager
The name of the queue manager for FileAct services via the MQSeries server. This must be the same
queue manager that is set up in SAG.
The SAG system administrator decides this.

esiadapter.famq.channel
The name of the MQSeries channel to use for the FileAct MQSeries low level interface.

esiadapter.famq.sslcipher
The name of the cipher to use if SSL communication is used between esiadapter and MQSeries
server. See esiadapter.finmq.sslcipher for details.

esiadapter.famq.client
The name of the queue for sending FileAct requests from ESIAdapter to SAG via an MQSeries server.
This must be the same queue name that is set up in SAG.

esiadapter.famq.client_ack
The name of the queue to receive responses from SAG relating to the requests sent via the
MQSeries server. This must be the same queue name that is set up in SAG.

esiadapter.famq.server
The name of the queue to receive incoming fileact requests from SAG via MQSeries server. This
must be the same queue name that is setup in SAG.

esiadapter.famq.server_ack
The name of the queue to send responses to SAG for requests from SAG. This must be the same
queue name that is setup in SAG.

esiadapter.famqfile.queue-manager
The queue manager used for the file transfer part of the MQSeries FileAct interface. Note that this
needs to be the same queue manager that is used for the request/response part of MQSeries
FileAct.

esiadapter.famqfile.putQ
The queue name for receiving file data from the SAG server.

esiadapter.famqfile.getQ
The queue name for sending the file data to the SAG server.

esiadapter.famqfile.commandQ
The queue name for the file transfer commands. This must be the same queue name that is set up
in SAG.

esiadapter.famqfile.commandAckQ
The queue name to receive acknowledgements from the commands sent on
esiadapter.famqfile.commandQ. This must be the same queue name that is set up in SAG.

esiadapter.finfile.dropdirectory
When writing files with FIN content, this directory must be created, and is where the files are
written. Example: /tmp/finfile

28

© Wall Street Systems IPH AB - Confidential

Configuration

esiadapter.finfile.pickupdirectory
When reading FIN content files, this directory must be created, and is where the files are read.
Example: /tmp/

esiadapter.mq.clientchannel.dir
The other MQ setup uses a configuration file that is named from the directory. For example:
/tmp/mq/clientchannel. The directory name must start with a '/'and use the Unix naming
convention.

esiadapter.destination.cmm
The name of the queue that CMM is listening to. Normally this would not need to be changed but if it
were necessary to redirect incoming messages that would normally go to CMM then changing this
value will change the name of the CMM queue. In a normal setup CMM will receive all FileAct,
MT101, and MT940 messages.

esiadapter.destination.trm
The name of the queue that TRM is listening to. Normally this would not need to be changed but if it
were necessary to redirect messages that would normally go to CMM, then changing this value will
change the name of the TRM queue. In a normal setup TRM receives all MT3XX messages. Note that
Accord messages are sent to a queue reserved for only accord messages.

esiadapter.fileact.transferep
The instance of swfa_handler to use for file transfer between the ESIAdapter server and the SAG
server.
The value can be anything, but it must match the command line arguments for the RAHA process
swfa_handler.exe. If this property is the default (=${wss.env.name}-WSS) and wss.env.name is
test1 then swfa_handler must be started as swfa_handler host:port:ssl test1-WSS.

esiadapter.fileactmq.remote-directory
The name of the directory on the SAG Server where files should be read and written when using the
MQSeries FileAct interface.

esiadapter.interact.username
The default value is the RAHA connection user name.

esiadapter.interact.password
The default value is the RAHA connection user password (encrypted).

esiadapter.interact.instance
The name of the message partner in SWIFT Alliance Gateway.

esiadapter.interact.strict
Specifies if the SAG interface for InterAct is set up to be strict (true) or relaxed (false).

esiadapter.interact.security.context
Specifies the distinguished name of the user that can log in to SAG for ACCORD's InterAct
application service.
If the FileAct and Interact user is the same, you can use the same distinguished name.
The SAG system administrator decides this.
If strict mode is used (esiadapter.rahaapi.interact.strict=true) then this value is determined
by ESIAdapter using the user and password information. This value can be left unset. If it is set,
then the value will be replaced by the one determined by ESIAdapter.

SWIFT Connectivity Guide

29

Configuration

esiadapter.interact.service
Specifies the service to be used with this InterAct interface.
Currently there is only one allowed value: SWIFT.ACCORD

esiadapter.interact.environment
Specifies if the environment is production, training, or testing.
Production: empty
Test and Training: !P
Integrated Test Bed: !X

esiadapter.interact.timeout
How long until RAHA disconnects. Expressed in milliseconds.

esiadapter.iamq.hostname
The resolvable hostname or IP address of the MQSeries server for InterAct MQSeries connectivity.

esiadapter.iamq.port
The port number of the listener for the queue manager used for InterAct connectivity with SAG.

esiadapter.iamq.queue-manager
The the name of the queue manager used to communicate InterAct traffic between ESIAdapter and
SAG. This must have the same name as the setup in SAG for the application interface.

esiadapter.iamq.channel
The name of the channel to use when connecting to the queue manager setup for connecting to an
application interface used for InterAct connectivity in SAG.

esiadapter.iamq.sslcipher
Name of cipher to use if SSL communication is enabled on the MQSeries channel.

esiadapter.iamq.client
The queue name for sending InterAct requests to SAG.

esiadapter.iamq.client_ack
The queue name for receiving responses to InterAct requests.

esiadapter.iamq.server
The queue name to receive requests from SAG.

esiadapter.iamq.server_ack
The queue name to send responses in reply to server requests.

esiadapter.interact.api
Which adapter to use for the InterAct message transport: RAHA - esiadapterIARahaLowLevel,
MQSeries - esiadapterIAMQLowLevel, MQSeries using a channel definition file esiadapterChannelIAMQLowLevel.

30

© Wall Street Systems IPH AB - Confidential

Configuration

esiadapter.trusted.hosts
The property is needed if SSL connectivity is being used. This may be the case with SWIFT Alliance
web services connectivity and if SSSL is used with MQSeries. If the property is empy then the host
name of the server that is being connected is not checked. A comma-separated list of host names
means that only hosts with these names are allowed to connect.

esiadapter.xmlverify.directory
(Syntactic checking of XML documents sent via the FileAct interface.)
The directory where all or additional XSD schema files are stored.

esiadapter.xmlverify.requesttype-pattern
(Syntactic checking of XML documents sent via the FileAct interface.)
If the request type sent with the Fileact request does not match the style of ISO20022:
(pain|camt|pacs|semt|setr|trea|)\\.\\d{3}\\.\\d{3}\\.\\d{2}.* then a matching regular
expression can be provided. For a list of supported schemas, see Appendix E ISO20022 supported
XSDs on page 281.

esiadapter.xmlverify.multi-message
(Syntactic checking of XML documents sent via the FileAct interface.)
Normally this value is set to false meaning that there is only one XML document per message. If
there could be more than one XML document, set this to true.

2.4.2.3 esiadapter-finswift.xml
All low level interfaces for FIN messages are specified in an XML format in the file
esiadapter.finswift.xml in the etc/onyx/properties directory.

2.4.2.3.1 Interface names
finalliance-1
The first key specifies the name of the interface. This name will used in the
esiadapter.finswift.api-list property and there will be an entry in the ESIAdapter FINSwift
Rules Editor with the same name.
Currently the following interface types are supported:

•

esiadapterFinFileType - basic file interface with raw FIN Message format.

•

esiadapterFinFileMervaType - basic file interface with EBCDIC and Merva file size at the
beginning.

•

esiadapterFinMQAllianceType - MQ Series interface to Swift Alliance Access via MQSA.

•

esiadapterFinMQMervaType - MQ Series interface to Merva Swift.

•

esiadapterFinCasMFType - CasMF interface to Swift Alliance Access.

•

esiadapterFinWSType - Web Services (SOAP) interface to Swift Alliance Access.

•

esiadapterFINMQHAXMLType - MQ Series interface to Swift Alliance Access via MQHA using
SWIFT XML V2 format.

•

esiadapterFINMQHAType - MQ Series interface to Swift Alliance Access via MQHA using MQ-MT
format.

•

esiadapterFileHBVType - basic file interface with HBV Message Format.

•

esiadapterACSHBVType - client-specific ACS interface delivering HBV Format messages.

•

esiadapterACSMervaType - client-specific ACS interface delivering Merva FIN Messages.

SWIFT Connectivity Guide

31

Configuration

2.4.2.3.2 Properties for esiadapterFinFileType
Example:
${suite.installer.esiadapter.finfile.dropdirectory}
key="pickup">${suite.installer.esiadapter.finfile.pickupdirectory}
key="error">${suite.installer.esiadapter.finfile.errordirectory}
key="ack-count">2

drop: the name of the directory where files containing fin messages will be written to when sent
from ESIAdapter. Note that there is no automatic cleanup of this directory.
pickup: the name of the directory where files containing fin messages will be read in by ESIAdapter.
Note that the file is deleted once the cycle is finished.
error: the name of the directory where rejected files are moved to. If this directory does not exist,
rejected files are deleted.
ack-count: the number of acknowledgements required. This depends on the setup.

2.4.2.3.3 Properties for esiadapterFinFileMervaType
Example:
${suite.installer.esiadapter.finfilemerva.dropdirectory}
${suite.installer.esiadapter.finfilemerva.pickupdirectory}
drop
The name of the directory where files containing fin messages will be written to when sent from
ESIAdapter. Note that there is no automatic cleanup of this directory.
picku
The name of the directory where files containing fin messages will be read in by ESIAdapter. Note
that the file is deleted once the cycle is finished.

2.4.2.3.4 Properties for esiadapterFinMQAllianceType and esiadapterFinMQMervaType
Example:
mqseries://swifthost:1415/SYSTEM.DEF.SVRCONN
key="queue-manager">QMSAA
key="receive-queue">QL.WSS.RCV
key="send-queue">QL.WSS.SEND
key="ack-queue">QL.WSS.ACK
key="timeout-period">-1
key="ack-count">3
key="sslcipher">

uri
The URI can take two forms.
The first uses the key word mqseries and indicates that the connection should use the host, port
and channel specified. Its format is mqseries://hostname:port number/channel name for example
mqseries://swifthost:1415/SYSTEM.DEF.SVRCONN.
The second form is for using a channel definition file and is of the standard MQSeries schema for a
channel definition file specification i.e. file://directory/file for example
file://c:/mqseries/channeldefs/QMSAA.tab.
In more detail:

•

32

swifthost
Example of the name or IP address of the MQSeries server with which the connection to SAA is
made. Use a legal machine name or IP address that is resolvable to the MQSeries Server
machine. The SAA system administrator decides this value.

© Wall Street Systems IPH AB - Confidential

Configuration

•

1415
Example of the port number for the listener for the Queue Manager by which the communication
to SAA is made. Must be the port number specified in the listener. Legal values are between 1024
and 65536. The SAA system administrator decides this value.

•

SYSTEM.DEF.SVRCONN
Example of the name of the channel used for FIN messaging to SAA. The channel is specified in
the Queue Manager specification in MQSeries as the server channel. It has a default value of
SYSTEM.DEF.SVRCONN. The SAA system administrator decides this value.

queue-manager
The name of the Queue Manager being used to communicate with SAA. Use the name of the queue
manager set up in MQSeries Server by which the communication to SAA is made. The SAA system
administrator decides this value.
The following shows the SAA window where the Queue Manager and Queues are set up for MQSeries
communication. The values used in ESIAdapter must reflect these:

receive-queue
The name of the queue that FIN Messages are received from SAA to ESIAdapter. The value must
reflect the name set up in SAA (and MQSeries Server) for outgoing messages. The SAA system
administrator decides this value. If messages are not to be received then this value can be left
empty. (No incoming messages will be received.)
send-queue
The name of the queue on which ESIAdapter sends FIN messages to SAA. The value must reflect the
name setup in SAA (and MQSeries Server) for the inward messages. The SAA system administrator
decides this value.
ack-queue
The name of the queue on which ESIAdapter listens for acknowledgement messages associated with
FIN messages sent from ESIAdapter to SAA. The value must reflect the name set up for
acknowledgement messages in SAA. The name of the acknowledgement queue can be the same as
the receive queue, but it must be specified.
timeout-period
The amount of time to wait for an initially sent FIN message to receive some acknowledgement
before considering that the SAA is not going to respond. The value is a number expressed in
milliseconds. This should be a large as possible without impinging on business requirements.
ack-count
The number of acknowledgements that will be arriving for a particular message. This number does
not include the delivery notification which is set in the ESIAdapter Client Relationship Editor. Allowed
values:
For the file simulator interface it must be 1 and delivery notifications turned off in ESIAdapter Client
Relationship Editor.
For MQ and Casmf interfaces it must be 3 and delivery notification can be either on or off depending
on the client preference.
sslcipher

SWIFT Connectivity Guide

33

Configuration

This specifies the SSL communication is to be used between ESIAdapter and MQSeries Server, and
the cipher to use. From the following table the Client Setting shows the value to use for sslcipher
for the assigned server side setting.
MQSeries server

esiadapter.finmq.sslcipher property

NULL_MD5

SSL_RSA_WITH_NULL_MD5

NULL_SHA

SSL_RSA_WITH_NULL_SHA

RC4_MD5_EXPORT

SSL_RSA_EXPORT_WITH_RC4_40_MD5

RC4_MD5_US

SSL_RSA_WITH_RC4_128_MD5

RC4_SHA_US

SSL_RSA_WITH_RC4_128_SHA

RC2_MD5_EXPORT

SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5

DES_SHA_EXPORT

SSL_RSA_WITH_DES_CBC_SHA

RC4_56_SHA_EXPORT1024

SSL_RSA_EXPORT1024_WITH_RC4_56_SHA

DES_SHA_EXPORT1024

SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA

TRIPLE_DES_SHA_US

SSL_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

SSL_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

SSL_RSA_WITH_AES_256_CBC_SHA

AES_SHA_US2
TLS_RSA_WITH_DES_CBC_SHA

SSL_RSA_WITH_DES_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA

FIPS_WITH_DES_CBC_SHA

SSL_RSA_FIPS_WITH_DES_CBC_SHA

FIPS_WITH_3DES_EDE_CBC_SHA

SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA

An empty value indicates that SSL communication should not be used. For further information see
2.4.6.4 ssl.properties on page 41.

2.4.2.3.5 Properties for esiadapterFinCasMFType
Example:
CASmfInOut1
key="max-outstanding">5
key="log-level">0
key="access-send-pass">
key="access-receive-pass">
key="data-send-pass">
key="data-receive-pass">

partner
The same value as for l_mapid in the DMAPID.DAT file.
max-outstanding
The maximum number of sent FIN messages allowed before some feedback is received. The value
must be less than or equal to the value of sess_wind in the DMAPID.DAT file.
log-level
The logging level for the C-code interface to CASmf. The value can be between 0 (log nothing) and 7
(log everything). This value should be set only if instructed to do so by Wall Street personnel.

34

© Wall Street Systems IPH AB - Confidential

Configuration

The following values are optional and need to be set only if authentication has been set up in SWIFT
Alliance Access. Note that there are two places where it is setup in SWIFT Alliance Access: the first
is for access and is on the Profile tab; the second is for data and is on the Authentication tab.
access-send-pass
The Send Key from the Profile tab. Note this is all 32 characters.
access-receive-pass
The Receive Key from the Profile tab. Note this is all 32 characters.
data-send-pass
The Send Key from the Authentication tab. Note this is all 32 characters.
data-receive-pass
The Receive Key from the Authentication tab. Note this is all 32 characters.

2.4.2.3.6 Properties for esiadapterFinWSType
endpoint
The URL to connect to the SWIFT Alliance Access http server. Normally this would be an https URL
with the name of the host, port number 48200 (unless the port has been changed), and the path is
soapha.For example: https://:48200/soapha.
partner
The name of the Application Interface given in SWIFT Allience Access.
user
The login for the user to login into the interface as.
password
The password of the user.
lau
If local authentication of SOAP traffic is required, this is the 32-character value that is set in the
Application Interface Authentication screen.
ack-count
The number of acknowledgements expected, not including Delivery Notification. The default value is
3 and depends upon the SAA setup.

2.4.2.3.7 Properties for esiadapterFinMQHAXMLType
connection-uri
A URI to specify all of the connection properties. See 2.4.2.3.4 Properties for
esiadapterFinMQAllianceType and esiadapterFinMQMervaType on page 32 for an explanation of the
styles that this URI can take.
queue-manager
The name of the queue manager as setup in MQ Series Server.
ccsid
The character code set identifier for character mapping. Normally 819 is a useable value but it may
need to be tuned for special cases.
receive-queue
The name of the queue which incoming FIN messages are received.
send-queue
The name of the queue to send FIN messages on.

SWIFT Connectivity Guide

35

Configuration

ack-queue
The name of the queue on which to receive acknowledgement messages. Note that this may be the
same as the receive queue depending on the setup.
cipher-suite
If specified forces the use of ssl connectivity. The list of ciphers is the same as for the MQSA
interface as this is an MQSeries feature.
user
If there is a user setup for the MQSeries connection, this is the user name.
password
The corresponding password for the above user.
send-lau
The local authentication for the Application Interface for the sending of messages to SWIFT.
receive-lau
The local authentication for the Application Interface for the receiving of normal messages from
SWIFT.
ack-lau
The local authentication for the Application Interface for the receiving of acknowledgement
messages from SWIFT.
ack-count
The number of acknowledgements expected not including Delivery Notification. The default value is
3 and depends on the SAA setup.

2.4.2.3.8 Properties for esiadapterFinMQHAType
uri
A URI to specify all of the connection properties. See 2.4.2.3.4 Properties for
esiadapterFinMQAllianceType and esiadapterFinMQMervaType on page 32 for an explanation of the
styles that this URI can take.
queue-manager
The name of the queue manager as set up in MQ Series Server.
receive-queue
The name of the queue which incoming FIN messages are received.
send-queue
The name of the queue to send FIN messages on.
ack-queue
The name of the queue on which to receive acknowledgement messages. Note that this may be the
same as the receive queue depending on the setup.
sslcipher
If specified, this forces the use of SSL connectivity. The list of ciphers is the same as for the MQSA
interface as this is an MQSeries feature.
timeout-period
How long to wait (in milliseconds) for any acknowledgement before assuming that the message has
been lost. A value of -1 means to wait forever.
ack-count

36

© Wall Street Systems IPH AB - Confidential

Configuration

The number of acknowledgements expected not including Delivery Notification. The default value is
3 and depends on the SAA setup. A value of 2 is used when using a MINT MQSeries interface, as
there is no initial "local" acknowledgement.
use-system-id
(Use only with the MINT MQSeries interface.) Can be either true or false. True means use the ID
from the actual FIN message (see tag 20 or 20C) as the correlation id does not contain any
information.

2.4.2.4 fileact.properties
This file can be found in the saa directory where SWIFT Alliance Access is installed. Here are the
properties in this file and their descriptions.

esiadapter.fileact.archive
If this property is used, it is the top level directory for archiving all sent and received data via the ftp
interface.

esiadapter.fileact.control.send
Directory where the sending control file is placed.

esiadapter.fileact.transport.send
Directory where the sending data file is placed.

esiadapter.fileact.control.receive
Directory where the receiving control file is to be picked up.

esiadapter.fileact.transport.receive
Directory where the receiving data file is to be picked up.

esiadapter.fileact.ftp.url
The URL of the ftp server. This may contain the port number and top level directory, for example
ftp://swifthost7/aft. Leave blank for the file interface.

esiadapter.fileact.ftp.user
The login user name for the ftp server. Leave blank for file interface.

esiadapter.fileact.ftp.password
The login password for the ftp server. Leave blank for file interface.

esiadapter.fileact.control.type
Can be either FTP or File. Note that this is case-sensitive.

esiadapter.fileact.transport.type
Can be either FTP or File. Note that this is case-sensitive.

2.4.3 ESIAdapter FINSwift API Rule Editor
2.4.3.1 Introduction
This editor enables users to determine which FIN messages should go to which FINSwift API.

SWIFT Connectivity Guide

37

Configuration

2.4.3.2 Usage
For each FINSwift API specified in the list associated with the property
esiadapter.finswift.api-list there should be an associated entry in this editor.

2.4.3.2.1 Fields
All fields, except for API Name and Priority are optional. Normally, the row with the least number of
filled-in fields will have the lowest priority (i.e. the largest numerical value).
Information

Description

API Name

The name of the API exactly as specified in esiadapter.finswift.api-list.

Priority

The smaller the number, the higher the priority. The highest priority should have
the most restrictive matching.

Matchable Senders

A regular expression that matches the Sender BIC. For example if the system has
multiple portfolio owners with their own BIC which need to send the FIN messages
via different interfaces then this would be the field to use to distinguish the cases.

Matchable Receivers

A regular expression that matches the Receiver BIC. In the case where different
receivers use different interfaces.

Matchable Request Types

A regular expression to match the FIN message type (MTxxx) for the case where it
is necessary to send different messages via different interfaces.

Matchable Target System

A regular expression to match site specific data that needs to be generated via
TRMSwift (field target_system).

Message Priority (U or N)

If urgent messages need to go via a particular interface indicate by U, normal
priority by N.

2.4.4 Esiadapter Module Name Rule Editor
2.4.4.1 Introduction
This editor allows you to specify to which module (TRM, CM, MATCH) particular incoming messages
should be sent. In a Wallstreet Suite installation, the main concern is how FIN messages should be
directed between CMM and TRM. There are also messages that are of no interest, for example
MT0xx informational messages, that neither system can act upon but may be sent by SWIFT or
counterparts.

2.4.4.2 Usage
In a TRM only environment, the CMM entry can be deleted and the field Matchable Request Types
updated to include any other MT messages that are expected to be received.
The default data found in this editor should be sufficient for all operations.

38

© Wall Street Systems IPH AB - Confidential

Configuration

2.4.4.3 Fields
Information

Description

Module Name

The name of the Wallstreet Suite component that the message will be sent to.
Currently there are three: CMM, TRMSWIFT, MATCH.

Default Module

If this is switched on, all unmatched messages are sent to this Module Name.

Interface Name

Internal name for the interface dealing with the particular message type.
Currently the value can only be FINSWIFT, FILEACT, or MATCH.

Matchable Senders

Regular expression to match the BIC of the sender (counterparty).

Matchable Receivers

Regular expression to match the BIC of the receiver. This is the user BIC of
Wallstreet Suite.

Matchable Request Types

List of FIN message types related to the selected module (TRMSWIFT, CM, or

MATCH). This can also be a regular expression.

2.4.5 Additional Connectivity to SWIFT Alliance Access
2.4.5.1 Introduction
With the introduction of SWIFT Allience Access(SAA) there has been a shift away from using the
MQSA interface for connecting applications to SAA. ESIadapter now offers three alternatives to
MQSA. The first is an MQHA interface using the MQ-MT format (see Application Interface for the
available content formats); the second is an MQHA interface using an XML format; the third uses the
SOAP (or Web Services) interface.

2.4.5.2 MQHA with MQ-MT
This interface is similar to MQSA: messages are sent in Network Dependent Format (NDF). The
problem with this interface is that Delivery Notifications are not automatically associated with the
original message sent. This interface is best used where Delivery Notifications are not required.

2.4.5.3 MQHA with XML
This interface uses a Network Independent Format (NIF) with an XML wrapper implemented in
SWIFT Version 2 format XML. This handles Delivery Notifications in a more sophisticated manner
than the MQ-MT format. Local authentication is also supported on this interface.

Note: Because the interface can be spread over three different Application Interfaces, it is
necessary to specify Local Authentication separately for each interface.

2.4.5.4 SOAP
The SOAP interface is similar to MQHA with XML in that the messages are sent in NIF format with a
SWIFT Version 2 XML format wrapper. The Application Interface setup is simpler, because only one
Application Interface is required. Similarly, if local authentication is required, both directions can be
handled by a single specified lau.

2.4.6 MQSeries and SSL
When using MQSeries as the interconnection for FIN message communication and where a VPN is
not used, it is necessary to enable SSL on the connection between the ESIAdapter MQSeries client
and the MQSeries server.
On the client side, the implementation of SSL in MQSeries Client uses the standard Java SSL
libraries, and handshaking verification is done using X509 certificates.

SWIFT Connectivity Guide

39

Configuration

On the server side, you should see the MQSeries documentation for the SSL configuration.

2.4.6.1 Encryption modes
The MQSeries Server setup determines the SSL encryption. There are three modes:

•

No encryption

•

Server verification

•

Client and Server verification.

With server verification, the client needs sufficient information in order to accept the server's
certificate. With client-side verification, the client needs to have a certificate that is signed by a
certificate that is acceptable to the server.

2.4.6.2 Creating the Java client's certificate
The following describes the steps to create the client side "store" for both the key and the trust side
using Java's keytool. You can use other programs such as openssl for creating the certificate
stores; however, the approach and the provisos are the same as those detailed here.

Note: In the examples below, modify names and passwords as required.
1. Create the Java client's personal certificate private key.
This step automatically generates the keystore.
keytool -genkey -dname "CN=JavaClientPersCert,O=Organisation,OU=OrgUnit,C=GB"
-alias MyJavaClient -storepass passw0rd -keypass passw0rd -keystore keyStore
-keyalg RSA -keysize 2048
Notes:

–

keyalg must be RSA

–

keysize must be 2048

–

There may need to be agreement with the server setup for dname.

–

dname should reflect your own organization.

2. Create the certificate request.
(A certificate from a Certificate Authority may be used instead of following this step.)
keytool -certreq -keystore keyStore -storepass passw0rd -keypass passw0rd -alias
MyJavaClient -file Client.req
Copy MyJavaClient.req to the machine that has the UNIX queue manager (and therefore the
key.kdb database).
Notes:

–

The file client.req must be signed with the private key of the certificate that the server has
the public key of.

3. Sign the certificate request.
Either a signed certificate is supplied by a Certificate Authority, or you copy the file client.req
to the server to be signed by the server's private key. The server, if local, can also sign the
certificate.
Whichever approach is used, the signed certificate and the public certificate of the signer must
be available to load into the store.
4. Import the CA certificate into the Java key store, keyStore
keytool -import -keystore keyStore -storepass passw0rd -alias TheCA -import -file
ca.cer

40

© Wall Street Systems IPH AB - Confidential

Configuration

Notes:

–

ca.cer is the public certificate of the signer.

5. Receive/import the signed certificate request back into the Java store keyStore
keytool -import -keystore keyStore -storepass passw0rd -alias MyJavaClient
-import -file MyJavaClient.sig
Notes:

–

The alias must be the same as used in step 1.

For further information see
http://www-01.ibm.com/support/docview.wss?uid=swg21168234&loc=en_US&cs=utf-8&lang=en

2.4.6.3 SSL setup for ESIAdapter
For ESIAdapter to use SSL, the property esiadapter.finmq.sslcipher must be set to a value.
Note that the server controls which value to use, but the naming conventions are different.
Therefore if the server specifies TRIPLE_DES_SHA_US, then the value to use is
SSL_RSA_WITH_3DES_EDE_CBC_SHA.

2.4.6.4 ssl.properties
The ssl.properties file controls the location of key and trust stores for the whole onyx service.
There are two areas where the SSL may be used. First is the internal communication via ActiveMQ,
and the second communication from ESIAdapter via MQSeries to SAA.
This section discusses the settings needed for MQSeries. It is assumed that the process of
generating a certificate file has been undertaken.

javax.net.debug
Java network extensions debug flag.
Values: { help, all, ssl [, record, handshake, keygen, session, defaultctx, sslctx,
sessioncache, keymanager, trustmanager, pluggability, handshake, data, verbose,
record, plaintext, packet] }
See http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security6.html and
http://setmpos.ykb.com/PosnetF1/yardim_tr/programlama/java/SunSSL/INSTALL.txt

javax.net.ssl.keyStoreType
The type of the KeyStore object that you want the default TrustManager to use. The default value is
the value returned by the KeyStore.getDefaultType method.
Value: PKCS12
Do not modify this property. However, if all certificates are in a single file, remove this property.

javax.net.ssl.keyStore
The name of the file that contains the KeyStore object that you want the default TrustManager to
use. The default value is jssecacerts, or cacerts (if jssecacerets does not exist).
Value: ${jupiter.certificates.dir}/onyx/onyx.p12
Do not modify this property.

javax.net.ssl.keyStorePassword
The password for the KeyStore object that you want the default TrustManager to use.
Value: ${ssl.connection.keyStorePassword}
See file credentials.properties.
Do not modify this property.

SWIFT Connectivity Guide

41

Configuration

javax.net.ssl.trustStoreType
The type of KeyStore object that you want the default TrustManager to use. The default value is the
value returned by the KeyStore.getDefaultType method.
Value: JKS
Do not modify this property. However, if all certificates are in a single file, remove this property.

javax.net.ssl.trustStore
The name of the file that contains the KeyStore object that you want the default TrustManager to
use. The default value is jssecacerts, or cacerts (if jssecacerets does not exist).
Value: ${jupiter.certificates.dir}/onyx/onyx.ts
Do not modify this property.

javax.net.ssl.trustStorePassword
This configures the trusted certificates database (trustStore) for the HTTPS connection.
Value: ${ssl.connection.trustStorePassword}
Do not modify this property. See 2.4.6.6 credential.properties on page 42.

2.4.6.5 Debugging
As SSL requires a complimentary setup on both the server and the client, the initial setup normally
takes more than one attempt. There are actions that can help ensure that the certificate file is
correct before starting the software. It is recommended that you run ESIAdapter in debug mode to
ensure that the output from debugging runs can be displayed and analyzed.
Key Store debugging

A useful command to run on the key store is:
Keytool -list.

Connection Debugging

With javax.net.debug set to ssl then a verbose version of the
handshaking is displayed. This information can be used to isolate which
aspect of the handshake is failing and so point to where the problem
lies.

2.4.6.6 credential.properties
2.4.6.6.1 The encrypt application
All passwords entered into the credentials.properties file must be encrypted first. The
application encrypt is used for the task.
Example:
C:\WSS-Suite\v7216\envs\esitest1\bin>encrypt
Secret key load failed - Defaulting to static secret key
====================================
Password Encrypter
Commands:
'1' -> Encrypt password
'2' -> Generate secret key
'3' -> Show current secret key
'0' -> Quit

42

© Wall Street Systems IPH AB - Confidential

Environment variables

Your choice:
1
Enter password :
abcqwerty
Encrypted password : 'DQ8Q7LsRj4PwXQkA'
The encrypted password within the quotes is the one that you enter in the file.

2.4.6.6.2 Properties
database.connection.username
The name of the database user. This user may be shared with other Onyx services. For ESIAdapter,
this user must have privileges to select, update, insert and delete on the tables:

•

ESIRequestEntry

•

ESISentEntry

•

ESILogEntry

The encrypted password for the user.

database.connection.password
The encrypted password for the database.connection.username above.

raha.connection.username
SWIFT Remote API Host Adapter (RAHA): this allows ESIAdapter to log into SAG via the RAHA
interface.
The user name must be the one supplied by the SAG system administrator.

raha.connection.password
The encrypted password for the raha.connection.username above.

ssl.connection.keyStorePassword / ssl.connection.trustStorePassword
SSL connection passwords: the passwords used for opening key store and trust store files for SSL.
Use the encrypted password that was used when creating the key store and trust store files.

2.5 Environment variables
ESIAdapter uses standard Onyx features for JMS and database connectivity. Normally the script for
starting the service will supply this information. ESIAdapter interfaces such as RAHA or CASmf can
have particular requirements for environment variables: refer to the relevant product
documentation for details.

2.6 Statuses
ESIAdapter stores the status of every payment/confirmation send to the SWIFT world in the
AdapterRequestEntry table.

SWIFT Connectivity Guide

43

ESIAdapter Client Relationship Editor

The two columns used to stores this status information are: current_state_id and max_state_id.
The current_state_id for FileAct messages can have the following values:
1

The message passed ESIAdapter and has been sent and accepted by the MQ series API or RAHA and
CASmf.

2

The message reached the SAA or SAG application.

3

ESIAdapter received an ACK Message from the SAA application (Message type F21).

4

ESIAdapter received a delivery notification from the counterparty (MT011 message).

-1

The message passed ESIAdapter and has been rejected by the MQSeries API.

-2

The message did not reach the SAA or SAG application.

-3

ESIAdapter received a NACK Message from the SAA application (Message type F21).

-4

ESIAdapter received a non-delivery notification from the counterparty (MT010 message).

2.7 ESIAdapter Client Relationship Editor
This editor supplies information that is needed by ESIAdapter. Everything is associated with the BIC
code (also known as the SWIFT Code in the Client Editor). The three pages contain information for
the supported SWIFT interfaces:

2.7.1 FIN Swift page
Description
Test BIC Code

Allows changing to a test setup without changing information in the editor.

Note: The Test BIC Code is currently not used.
Delivery Notification

Switched on means that final verification of the successful arrival of a FIN
message is required. This is a service for which SWIFT charges.

2.7.2 FileAct page
Depending on the request type, there can be multiple entries here.
Description
User Name

Name for describing this entry.

Request Type

For an outgoing FileAct request, this is the request type that is supplied by
application (CMM). The BIC code/Request Type Name are used for looking up the
correct instance of the correct instance. The data included in the request is from
Request Type, Distinguished Name and File Information.
For an incoming FileAct request, this is the value for Request Type that is passed
to the application (CMM) after a reverse lookup of Request Type, Distinguished
Name and File Information (on the specified File Information Keys).

Request Type Name

Optional. The value could look like this example: pain.fin.mt101 or

camt.xxx.cfonb120.stm
Distinguished Name

The value that is to be used for either receiver or responder (depending on
whether the client is sending or receiving). Its format is like the example below,
but can be more complicated.
Example: o=ptsggbee,o=swift

44

© Wall Street Systems IPH AB - Confidential

ESIAdapter Client Relationship Editor

Description
Service Name

Value to set the service name field in the fileact request if the default
(swift.corp) is not the correct one to use. Note that this is very rarely used.

File Information

This is the information that is expected in the fileinfo field of the Fileact
Request. It should contain at least SwCompression=None (or Gzip) but may
require more information depending on the bank’s requirements. All key value
pairs must be specified with an equals sign (=) and separated by a semi-colon (;
). For example:

SwCompression=None;FileType=XXXX;CustomerId=100000.
File Information Keys

This determines which fileinfo keys should be compared with the contents of
the File Information field when there is an incoming FileAct request. This is used
to determine the Request Type and BIC code. The complete comparison takes
into account:
•

The Request Type Name, which is compared to the requesttype field in the
request,

•

The Distinguished Name, which is compared to the requestor.

•

The values in File Information, which is compared to the fileinfo field, but
only for the key(s) specified in this field. If there should be more than one
key, separate them with commas.

For example, if
File Information: SwCompression;FileType=XXXX;CustomerId=10000
and
File Information Keys: FileType
then the value XXXX would be compared to the same value from the fileinfo field.
Transfer Information

This is the data that the counterpart requires in the TransferInfo field of the
Fileact Request. The field is optional; if left blank, it will be filled with data.
It should only be filled if the counterpart specifically requests pecific information
to be provided in this field. Unlike File Information, there are no formatting
requirements.

Transfer Information Keys

Similarly to File Information Keys, the Transfer Information Keys field specifies
which keys to use if the TransferInfo field data is used to supplement the
information received in the RequestType field for an incoming FileAct request.

Logical File Name Format

(Optional)
The logical name included in the FileAct request. You can include wildcards like
this:

%ns or %nd
Where:

 is the filename
% means the start of the wildcard part

n is a number that represents the width of the variable portion
s means that the unique ID of the request should be used
d means that an internal numeric value that is incremented should be used.
Compression Algorithm

The actual compression algorithm to select and use. Values include NONE, GZIP
or ZIP.

Note: Bank A may have Compression Name ABC and compression algorithm
GZIP and bank B have Compression Name XYZ and compression algorithm
GZIP but normally they would have Name Gzip and algorithm GZIP.
NR Indicator

Non-repudiation indicator. Should always be switched on for a corporate, but is
optional for a bank.

Need Crypto

Should always be switched on. Indicates that SSL is needed.

SWIFT Connectivity Guide

45

RAHA

Description
Acknowledgement Request

Switched on if there should be an acknowledgement received for the outgoing
message. For corporates this must be switched on, but is optional for banks.

2.7.3 Accord page
There can be multiple entries here, but the normal case is one entry.
Description
Query BIC Code

The BIC code that the Accord system understands (typically the same but it might
be with or without XXX at the end).

Test Query BIC Code

The test BIC code is so that the test system could be used but it may have a
different BIC code without needing to change the setup.

Distinguished Name

The Distinguished Name of the requestor. This can be different to the one used for
FileAct.

Message Types

The relationship to the MT confirmation message that is used in the comparison.
300,320 would be the norm at the moment but it will grow with time.

Need Crypto

Should always be switched on.

NR Indicator

Should always be switched on.

2.8 RAHA
RAHA has its own environment variable which points to the configuration directory for the instance
being used. More than one instance may be necessary, depending upon the setup used for test and
production.
The path environment variable must include the shared library directory of RAHA. For example, if
RAHA is installed in C:\SWIFTAlliance\RA, and the instance is called RA1, then the following actions
are required:

Example using Windows:
SET SWNET_CFG_PATH=C:\SWIFTAlliance\RA\RA1\cfg
SET PATH=%PATH%;C:\SWIFTAlliance\RA\lib
To start the Ra1 Remote API:
C:\WINDOWS\system32\cmd.exe /K C:\SWIFTAlliance\RA\bin\swiftnet.bat init -S Ra1
If necessary, you can test the SAG connection as follows:
cd C:\SWIFTAlliance\RA\bin
sag_test_connect.exe
C:\SWIFTAlliance\RA\bin>sag_test_connect.exe
Enter the SWIFTNet user name: Sbei-fileact-myusrname
Enter the password for SWIFTNet user Sbei-fileact-myusrname: ******************
Sending InitRequest
Received InitResponse
Sending CreateContextRequest
Received CreateContextResponse
Sending ConnectivityRequest

46

© Wall Street Systems IPH AB - Confidential

Starting ESIAdapter with Process Monitor

Received ConnectivityResponse
Sending DestroyContextRequest
Received DestroyContextResponse
Sending TermRequest
Received TermResponse
SWIFTAlliance Gateway connectivity test completed successfully.

Important: All directories specified in the configuration should be created and access

permissions verified for the user that will be running the esiadapter process. If you
use Process Monitor (PMM), then the user running the process is called SYSTEM.

2.9 Starting ESIAdapter with Process Monitor
If WSS Suite is installed using the Suite Installer, there is a setup that enables the launching of
ESIAdapter as an Onyx service, and the anciliary process needed by SAG/RAHA if using the FileAct
interface. Setting the properties in esiadapter.properties is not covered by the Suite Installer,
and so this procedure must be done before attempting to start the processes using Process Monitor
(PMM).

2.9.1 Processes in PMM
This description is for the esiadapter_onyx process as seen in the Process Monitor screen.

2.9.2 Assumptions
It is assumed that the setup is for ESIAdapter using RAHA for FileAct. In all other cases the
raha_handler does not need to be configured.

2.9.3 ESIAdapter and PMM configuration procedure
After in installation made with the Suite Installer, you should complete these steps:
1. Install RAHA and note both the installation directory and the installation instance (normally Ra1).
2. Adjust the envs/$env-name/etc/environment/parts/15_esiadapter.bat so that the following
parameters are set using the information you noted above.
SET PATH=C:\SWIFTAlliance\ra\lib;%PATH%
Ensure that c:\SWIFTAlliance\ra is the same as the installation directory from above.
SET SWNET_CFG_PATH=C:\SWIFTAlliance\RA\Ra2\cfg
Ensure that C:\SWIFTAlliance\RA is the same as your installation directory (from above) and
that Ra2 is changed to your installation instance (from above). Ensure that the directories
specified in the file are in a suitable location for both capacity and redundancy.
3. Edit esiadapter.properties, credential.properties, and ssl.properties as necessary.
4. Create a command window using envs/$env-name/bin/trm-$env-name-shell.bat.
In this command window verify that ESIAdapter will start by typing
onyx.bat esiadapter
If there is a failure, a error message will appear in the output.
5. Fix any failures. Here are problems you may encounter:

–

Can't load library because PATH is incorrect.

SWIFT Connectivity Guide

47

File Simulation Mode

Set correctly in 15_esiadapter.bat

–

Can't find configuration file because SWNET_CFG_PATH is incorrect.
Set correctly in 15_esiadapter.bat

–

Can't open directories because of no existence.
Verify that the path is the one required and create directories as necessary.

2.9.3.1 RAHA
With RAHA, the next level of problems normally relate to incorrect passwords, application interfaces,
and strict/relaxed setup. An incorrect database user/password will also cause a failure as does lack
of permissions on the database tables.
Once the ESIAdapter Onyx process can start and run continuously in the command window, this
proves that it is possible to run it from PMM.

2.10 File Simulation Mode
To help with system setup and debugging the setup of other modules, ESIAdapter is supplied by
default in file simulation mode for both FileAct and FIN. This is useful for the initial installation and
testing as it replaces some third party software. However, there is still a need for connectivity via
RAHA and MQSeries.

2.10.1 FileAct simulation
The FileAct simulation requires a directory called esiadapter.rahasimulatorapi.dir in the
esiadapter.properties file. Under this directory are two directories: in and out, each of these
containing two directories props and data.
When a FileAct message is sent via ESIAdapter, the data is written to unique-id.txt in the
out/data directory. The relevant properties are written to unique-id.props in the out/props
directory.
To simulate a FileAct request coming from a counterparty, the data file unique-id.txt is put in
in/data and a properties file unique-id.props is placed in in/props. The properties that must be
supplied are:
requestor=o\=socgenfr,o\=swift
responder=o\=veolfree,o\=swift
service=swift.corp!p
requesttype=pain.xxx.cfonb120
fileinfo=SwCompression\=None;FileType\=xxx

Note: The ACK Indicator must be turned off for senders.

2.10.2 FIN simulation
The FIN file interface uses two directories; it also writes and expects a well-formed MT message
without additional characters (for example Alliance, MERVA demarcation markers). It expects only
one message per incoming file, and writes only one message per outgoing file.
The directories used are:
/tmp/finfile for the drop directory
/tmp for the pickup directory

48

© Wall Street Systems IPH AB - Confidential

ESIAdapter simulator

These directories must exist.

Note: Delivery Notification must be turned off for senders.

2.10.3 Changing from simulation mode
When changing from the file simulation mode to third party interface mode, the number of ACKs
needs to be updated.
For FIN, the parameter to change is in the esiadapter-finswift.xml file:
3
where the value should be set to 1 for simulation mode, otherwise it should be 3.
The value of delivery notification in the ESIAdapter Client Relationship Editor for senders is
important; in file simulation mode, if you do not receive the final acknowledgement then this switch
should be checked, otherwise it should be unchecked.
Currently the SWIFT Accord interface is always associated with RAHA or MQSeries and so will cause
problems if a default ESIAdapter is started. This can be overcome by setting the environment
variable MODULES_ESIADAPTER_SYSTEM=fin-fileact.

2.11 ESIAdapter simulator
There is an ESIAdapter simulator for sending incoming messages to either CMM or TRM. The
program requires a file with the data that is to be sent.

Note: In the case of FileAct, the file must be uncompressed before sending.
The simulator can also be used for sending messages to the SWIFT network via ESIAdapter.
The program is a python script called esiadapter-simulator.py in the %FK_HOME%\bin directory.

2.11.1 Simulating sending a FIN message
To simulate a FIN message, use the following syntax:
python esiadapter-simulator.py -a true|false cmm|trm fin  
 
Where:
-a

Required only in a Windows environment

true or false

true: send to ESIAdapter. false: send to CMM/TRM.

cmm|trm

Specifies to which module you wish to send the message.

fin

Specifies a FIN message (as opposed to a FileAct message).



The name of the FIN file that contains the content to send.

Note: Remove blocks 1 and 2 from the original FIN message.


BIC code of the recipient (CMM or TRM).



BIC code of the sender (the bank).



The message type, for example 101, 300, 320, 940, 950 and so on.

2.11.2 Simulating sending a FileAct message
To simulate a FileAct message, use the following syntax:

SWIFT Connectivity Guide

49

ESIAdapter simulator

python esiadapter-simulator.py -a true|false cmm|trm fin  
   []
Where:
-a

Required only in a Windows environment.

true or false

true: send to ESIAdapter. false: send to CMM/TRM.

cmm|trm

Specifies to which module you wish to send the message.

fileact

Specifies a FileAct message (as opposed to a FIN message).



The name of the file that contains the content to send.



BIC code of the recipient (CMM or TRM).



BIC code of the sender (the bank).



The business area, for example pain or camt.

 [] The message syntax and format used, for example xxx.confb120,
followed by an optional description, for example stmt.

50

© Wall Street Systems IPH AB - Confidential

Chapter 3

CASmf configuration

CASmf is made up of a number of background processes and an API library. The background
processes interact with the API and subsequently with SWIFTAlliance via sockets-based
communication.
The API supplied with CASmf has been repackaged as a shared library with an additional layer of
software that conforms to the JNI standard. This enables Java software to interact with external
C-based libraries.
Calls to the CASmf API from TRMSwift use the native interface.

3.1 Installing CASmf
CASmf must be installed on the same server as the TRMSwift CASmf adapter. See the CASmf
documentation for full details on installing CASmf.
The TRMSwift superuser must have permissions to write to all files in the CASmf directories. It is
recommended but not essential that you use the same user for TRMSwift and CASmf.

3.2 Configuring CASmf
3.2.1 Modifying the dmapid.dat file
Once you have installed CASmf, you must modify the file dmapid.dat which is stored in the dat
directory. This directory is typically created in Program Files\SWIFT\CASmf on Windows NT and in
/usr/casmf/SunOS on Solaris.
Here is an example of how the contents of this file should appear:
cas_version2
app_typ

MXA

l_mapid

CASmfInOut1

r_mapid

AllianceMXSCASmfInOut1

enable

1

net_protocolTCP
net_laccess5101 (Example port number from SWIFTAlliance machine)
net_raccess5101
net_rhost SWIFTAlliance computer IP Address
sess_flow 2

SWIFT Connectivity Guide

51

Configuring SWIFTAlliance

sess_wind 1
end

yes

check_bic8BANK'S BIC CODE
check_pass1Security number 1.
check_pass2Security number 2.
Note the following points:

•

r_mapid must be AllianceMXS + l_mapid.

•

l_mapid is the name of the interface setup in SWIFTAlliance.

•

net_raccess is the port number from the services file. This is associated with the name used in
the setup of the named interface.

•

net_raccess must be the same as net_laccess if CASmf and SWIFTAlliance are running on
machines with different IP addresses.

•

net_raccess is the port that SWIFTAlliance listens on for connections.

•

net_laccess is the port that CASmf listens on for replies.

•

The security officers must supply check_pass1 and check_pass2.

3.2.2 Setting environment variables
You must set the following variables:

•

CUS

•

CUSSYS

•

DATTOP

•

LOGTOP

•

CUSCFG

•

DMAPID.

See the CASmf User Guide for information about these variables.

3.3 Configuring SWIFTAlliance
You must set up a SWIFTAlliance interface. This procedure is explained in the CASmf
documentation, however you should note the following points:

•

The interface name must be the same as that specified in the file dmapid.dat (see previous
section). The default name used by TRMSwift is CASmfInOut1.

•

The flow must be bi-directional.

•

The connection must be initiated by the application and not by SWIFTAlliance.

3.3.1 SWIFTAlliance Security
SWIFT's CASmf protocol does not support encryption but it does support authentication when
sending data between TRMSwift and SWIFTAlliance Access.
There are three basic levels of authentication:

•
52

None (AUTH_NONE)

© Wall Street Systems IPH AB - Confidential

Configuring SWIFTAlliance

•

Authentication upon opening the connection (AUTH_ACCESS)

•

Authentication when data is sent (AUTH_BOTH).

The CASmf API remembers the authentication keys supplied with the required level of
authentication. The level of authentication is automatically determined by the passwords provided.
Authentication keys can be passed as environment variables on startup.
There are four authentication keys:

•

ACCESS_SEND_PASS: calculates the authentication on the data to be sent during session
opening. Mandatory if access authentication is used (AUTH_ACCESS or AUTH_BOTH)

•

ACCESS_RECEIVE_PASS: verifies the authentication on the data received during session
opening. Mandatory if access authentication is used (AUTH_ACCESS or AUTH_BOTH)

•

DATA_SEND_PASS: calculates the authentication on the data to be sent during session opening.
Mandatory if data authentication is used (AUTH_BOTH)

•

DATA_RECEIVE_PASS: verifies the authentication on the data received during the current
session. Mandatory if data authentication is used (AUTH_BOTH).

If ACCESS_SEND_PASS is passed but DATA_SEND_PASS is left empty, authorization is only done
upon opening the connection between TRMSwift and SWIFTAlliance Access.
If ACCESS_SEND_PASS and DATA_SEND_PASS are provided, the authentication level is set to the
sending of data on opening the connection (AUTH_BOTH).
If none of the authentication keys are provided, no authentication is done.
You must set up the corresponding authentication keys in SWIFTAlliance Access.
For more information, see the CASmf Programmers Guide and the SWIFTAlliance Access Security
Guide.

3.3.2 Receiving a failure (NACK) from SWIFTAlliance
When receiving a failure (or NACK) from SWIFTAlliance via CASmf, various fields are included in the
feederfeedback section of the message. The data in these fields depends on whether the reply
comes from a logical reply or a transmission/delivery report. Each type is shown in the examples
below:

3.3.2.1 NACK received from a transmission or delivery report




REPORT
fail
TRANSMIS_REP
3
Network Nacknowledged





SWIFT Connectivity Guide

53

Configuring TRMSwift

3.3.2.1.1 NACK received from a reply




REPLY


2
2




The table below describes the XML items in these two examples.
Item

Description

message_type

Contains the type of message that indicated that a failure
happened. Possible values: REPORT or REPLY.

report_success

Indicates that a failure has occurred. Contains data only for the
message type REPORT.

report_type

Contains the type of report that was received. Contains data only
for the message type REPORT. Possible values include:
•

TRANSMIS_REP: Transmission Report.

•

DELIVERY_REP: Delivery Report.

•

PROCESSI_REP: Processing (Information) Report. When
sending an Information Report to TRMSwift from
SWIFTAlliance, the message is considered as a failure; this
indicates that the message should be rejected.

failure_reason

Indicates the message failure reason code (as supplied by
CASmf).

failure_reason_text

Indicates in plain language the reason why the message failed.

3.4 Configuring TRMSwift
Although TRMSwift is supplied with a default adapter configuration for CASmf, this is not activated
by default. Likewise, the rules for sending SWIFT messages are not configured to include the CASmf
interface.
To activate the CASmf adapter configuration:
1. Activate the library file.

–

On Windows, the files cus.2.2.dll and cus.6.0.dll are in [ROOT]\bin. Rename the file
for your CASMF version to cus.dll.

–

On Unix, the files libcus.2.2.so and libcus.6.0.so are in [ROOT]\lib. Rename the file
for your CASMF version to libcus.so.

2. Include this directory in the PATH environment variable (Windows) or the LD_LIBRARY_PATH
(Solaris).
3. Edit the custom.properties file to include the word CASMF on the line where
ikit.feeder.component is specified.

54

© Wall Street Systems IPH AB - Confidential

Debugging

4. Start TRMSwift.
The rules for sending SWIFT messages must be modified to include the CASmf interface. In
rules.xml the OMH_Swift action should include:




Note that a more specialized flag can be setup in setup.xml and applied to the action.

3.5 Debugging
The CASmf log contains details of errors that may occur. This file is stored in the log directory of the
CASmf installation and is called cuslog.log.
Some possible errors are:

•

If the values for check_pass1 or check_pass2 are incorrect, you will receive an error message
that only 100 messages will be passed.

•

TRMSwift produces error messages if the connection with shared library has failed or if the
library cannot be found.

•

Messages are successfully delivered to SWIFTAlliance but fail to be accepted on formatting
grounds. The problem may be with the sender's SWIFT code as it often has an incorrect value in
field 9.

Note: When initiating a connection, CASmf reports an error about an incorrect APDU header. You
can ignore this error.

If you are using a test environment, you can set the SWIFT_TRAINING environment variable to
ensure that messages are not sent as live messages.

SWIFT Connectivity Guide

55

Debugging

56

© Wall Street Systems IPH AB - Confidential

Chapter 4

FIN messaging configuration

4.1 FIN messaging components
The components between TRMSwift and the Enterprise Swift Integration Adapter (ESIAdapter) are
responsible for updating the FIN Message Manager, as well as for facilitating communication with
TRMSwift and ESIAdapter. These components are not apparent to users.
Use of the components is driven by the FINMessage flow, either because they are triggered from
there (e.g. sending a message or responding to TRMSwift with a status update) or because they
trigger the flow (e.g. receiving a new message to send, receiving a new message that has been
received or receiving a status update from ESIAdapter about a message that has been received).

SWIFT Connectivity Guide

57

FIN messaging components

4.1.1 FIN Messaging flow diagram

Q02

FIN Message Admin

Q03

Processing driven
by TRM Entity
Flow and FIN
Message Admin

TRMSWIFT
Responder
Failure

Database

FIN
Message
Writer
Sending
FIN

TRMSwift
Queue
Adapter

FIN Message status update

Q04

Incoming
FIN
For
CMM

serviced

Q07

Entity
DoAction

TRMSWIFT
Receiver

Incoming FIN

Q06

Q11

serviced

Delivery
Notification
ACK/NACK
received
Local Report
received

Failure

Q08

TRMSWIFT
Sender

Outgoing
FIN

ESI
Adapter

Q09

FIN
Outgoing

CMM
(WebSuite)

XML
Framework

FIN
Message
Response
on
Outgoing
FIN

SAA
SAG

FIN/FileAct
Outgoing
FileAct Status
Q05

Q10

Incoming
FileAct

Q01

Queue names:
Q01 $(wss.env.name).finmessage.cm.status
Q02 $(wss.env.name).finmessage.to.trmswift
Q03 $(wss.env.name).finmessage.status
Q04 $(wss.env.name).finmessage.writer
Q05 $(wss.env.name).esiadapter.cm-status
Q06 $(wss.env.name).match.finmessage
Q07 $(wss.env.name).esiadapter.trm
Q08 $(wss.env.name).finmessage.send
Q09 $(wss.env.name).esiadapter.in
Q10 $(wss.env.name).finmessage.cm
Q11 $(wss.env.name).esiadapter.trm-status

58

© Wall Street Systems IPH AB - Confidential

FIN messaging components

4.1.1.1 FINWriter saves the message in the database
The FIN Message Writer component receives FIN messages formatted by TRMSwift, and saves them
(on Q04) to the database as FIN messages in a format that can be manipulated easily. The header is
saved in the FINMessage table and the content (blocks 3 and 4) is saved in the FINMessageField
table.
It creates the FINMessage entity and saves it to the database via the COMMIT action (in the FIN
message flow).
This would also typically be the point where the FINFormat rules and actions are run for updating
the message with any changes that need to be made (see 4.3 FIN Message Rule Editor on page 65
and 4.4 FIN Message Action Editor on page 68.)
If the message cannot be processed or the FIN Message Writer is not running, a failure status is
returned to TRMSwift via the TRMSwift Responder.

4.1.1.2 FINsend sends message to adapter
The TRMSwift FINSend component (Sender) passes the FIN message to the adapter. This happens
when a user accepted the message in the flow, or the flow is configured for Straight Through
Processing. The flow puts it on Q08.
The Sender does the following:
1. Creates the formatted message before passing it on (Q09). This is done based on the content of
the FINMessage and FINMessageField tables which it receives on Q08.
2. Receives an immediate response back (Q06) from the adapter framework after it performs some
validatation.
3. If the response is OK, then further status updates are received.
4. If the response is not OK, it pushes it onto Q06 with a failure, where the REJECT action is called
on the FINMessage object.
The rest of the processing depends on the FINMessage flow.

4.1.1.3 TRMSWIFT Receiver receives status for sent messages
The TRMSWIFT Receiver component is used to receive statuses about messages already sent, or to
receive new messages from the ESIadapter.
1. If a status update is received (Q07), the database is updated accordingly by putting an XSD
message on the EntityDoAction serviced provider’s queue (Q06).
2. It then updates the database by setting the status of the FINMessage entity and calling the
appropriate entity broker action.
3. In a typical flow setup, the message will be pushed to the next state if the received status
indicates success, or reject if it indicates a failure. If it is a failure, no further updates are
expected.

4.1.1.4 Receiver receives new messages
The TRMSWIFT Receiver is also used to receive new messages from ESIAdapter.
1. If a new message is received (Q07), an XSD structure is populated with the relevant data and is
passed on to the fin-message/writer serviced provider (Q04).
2. This saves it to the database by calling the (FIN message) entity broker COMMIT action.
3. A new ID is generated using NewOrderNumber, starting at and counting down from -1.

4.1.1.5 Responder responds with status updates
In the FINMessage flow, when a message has been sent completely or when it has been rejected (or
failed), the TRMSwiftResponder returns an success or failure status back to TRMSwift, so that the
corresponding transaction or settlement can be updated. The decision of success or failure is based

SWIFT Connectivity Guide

59

FIN messaging components

on the flow configuration. In a typical flow, reaching the Sent state indicates success, while being
rejected indicates a failure.

4.1.1.6 CMM FIN messages monitored on FIN Message Manager
Outgoing FIN messages from CMM (WebSuite) are sent to ESIAdapter via FIN Message Manager
(Q04, Q08, Q09), or directly using SwiftNet Adapter communication protocol (Q09).
In order for the outgoing messages to be managed (from both TRM and WebSuite) they must go
through FIN Message Admin.
Incoming FIN messages now come from ESIAdapter via FIN Message Manager (Q07,Q04,Q10). This
means that users can monitor CMM-related FIN messages as well as TRM-related ones from FIN
Message Manager (TRM users) or a web-based FIN Message Manager (WebSuite users).

Note: FileAct flows remain unchanged: direct connection between ESIAdapter and CMM.

60

© Wall Street Systems IPH AB - Confidential

FIN message administration (TRM)

4.2 FIN message administration (TRM)
You can view and manage FIN messages to and from SWIFT using the FIN Message Admin
application, available from Application Manager. This manages the flow of FIN messages between
TRMSwift, CMM, and ESIAdapter. The application has the same look and feel as a Wallstreet Suite
transaction board, with standard features including flow control (accept, reject, etc), layouts, queue
capabilities, and modes.

Note: Most of the non-FIN specific fields are lookups on the underlying transactions, not the

settlement, so appear to be updated when the underlying transaction's values are
updated. The values correspond to what is in Query view, where you can also query based
on transaction values.

You can configure straight-through processing or multiple verification, and manage it from this
application.

The application has these views:

•

Query view
Used for querying FIN messages based on limited transaction information, on limited cash
management cash record related information or on the FIN message header itself. Note that
cash management-related information is prefixed with CMM.

•

Header view
Displays information from block 1 and 2 of the FIN message. Most of these fields can be queried.

SWIFT Connectivity Guide

61

FIN message administration (TRM)

Field view

•

Displays the various fields that make up blocks 3 and 4 of the FIN message. For each block the
information is shown as a table to make it easier to work with. Each row that appears in this
view corresponds to a line in the formatted FIN message.
Block 5 fields contain the User or System Trailers in the column Tag and the content of the
Trailer is stored in the Text column.
If the FIN Message is re-sequenced from several incoming messages, then block 2 from the last
message received is parsed into the Header view and block 5 is not parsed.
If a field (for example, :72:) has multiple lines, each line appears as a separate row with a
different order id.
The Block, Tag and Tag Option fields are the same, but from the second line onwards the "hide
tag" flag is set to Yes to indicate that from the second line onwards the tag and tag option should
be hidden.
The Block and Order id columns are used to determine where in the final formatted FIN message
the information is placed. The "modify tag" field indicates if the field can be modified in the FIN
Message Manager (provided that it has not yet been sent).
Where a message has a field with multiple lines or has repeating tags, the optional Fin Sequence
and Subfield columns may be used as an identifier rather than relying on the order id (Order
column in the Field view). The Fin Sequence displays the name of the SWIFT sequence where
the field exists, or is blank where the type of message contains no sequences (MT202 for
example). The Subfield contains text that describes the purpose of the field to help identify it.
This enables users to easily identify which values they want to override.
Cash Record view

•

Shows cash record cash management elements. Elements shown directly correspond to the cash
record(s) making up the body of the selected FIN messages. The Release Batch ID or to the
Cash Record ID itself makes it easy to find the corresponding FIN message and to know the
actual status of the cash record(s) after it has been released from CMM.
Changes that are made to FIN messages (including verification, receiving of ACK/NACK,
matching/unmatching) are logged for the header, and made available via a report (the TRMSwift FIN
Message Log Report). The header of the FIN message is logged, but not the individual field changes.

4.2.1 Previewing changes to FIN messages
You can preview changes to FIN Messages before saving the changes. You use the Process Actions
action on a FIN message to see what changes will be made to the message if the FIN Format Rules
and Actions were to be applied. The changes can be Reset, the rules and actions modified, and
previewed again to refine what the actions should do.

4.2.2 FIN message administration (WebSuite)
WebSuite also has its own web-based FIN message administration. The web-based version offers all
the functionality of the rich client FIN Message Admin application except for real time, and the
normal constraints of web pages (no flexible layouts).
To launch it, select Payment Factory - Processing - Message Admin
Query pages are dedicated either to cash management-related queries or to treasury-related
queries. Queries run from these pages are equivalent to queries run from the rich client FIN
Message Admin (Query view).

Hint:

62

In the FIN Message Cash Management Search below, the difference between Release
Batch ID and CMM Release Batch ID is as follows:
Release Batch ID: Auto-generated by CMM upon release of a cash record. It uniquely
identifies each FIN message released to TRMSwift. Typically, where the cash record release
results in the creation of two messages, each of them will share the same CMM Release

© Wall Street Systems IPH AB - Confidential

FIN message administration (TRM)

Batch ID but will have a different Release Batch ID or Message ID. Message IDs can be
viewed in the job details.
CMM Release Batch ID: Aauto-generated by CMM upon release of one or more cash
records. It corresponds to the ID of the CMM release job. Typically if several cash records
are released as part of the same batch/job, they share the same CMM Release Batch ID or
Import Export Log ID.

Treasury and cash management result pages are different. However, both result pages present the
same information as far as the corresponding FIN message is concerned. Information displayed in
the WebSuite version is equivalent to the information displayed in the rich client FIN Message Admin
(FIN Message View).
In results pages, you can push messages into the entity flow. To do that, you need to select an
action to perform from the Action column and click Apply. Note that the actions available vary from
one message to another, depending on the type of message and its state in the flow.

SWIFT Connectivity Guide

63

FIN message administration (TRM)

By clicking the ID of the message (link in the FIN Message ID column), you can view the details of
the corresponding FIN message. This is similar to the rich client FIN Message Admin (Fin Message
Field view).

64

© Wall Street Systems IPH AB - Confidential

FIN Message Rule Editor

Note: If a FIN message results from CMM initiated payments, related cash record details will

show at the bottom of the result/detailed page (like in the Cash Record view of the rich
client FIN Message Admin).

Hint:

There is no real time updating. Where the application of an entity flow action results in the
messages going through several states, it might be necessary to execute the Refresh Static
Data to display the latest available state for this message. See the screenshot below.

4.2.2.1 FIN message label mapping
This table summarizes the FIN message label correspondence among different areas of the
Wallstreet Suite:
Application screen
FIN Message
Admin (TRM)

Message
Admin
(WebSuite)

Database table elements
Review Job
Log
(WebSuite)

CASHRECORD

EXPORTMESSAGE FIN Message

CMM Cash
Record ID

CMM Cash
Record ID

N/A

ID

N/A

Related
Reference

Release Batch ID

Release Batch
ID

JobLogID

ImportExportID/

ImportExportID

Reference

CMMRelease
BatchID

Not available

Message ID

N/A

ID

ReleaseBatch
ID

ID

FIN Message
ID

N/A

N/A

ID

ReleaseBatchID

(in
Communication
Log Details)
N/A

4.3 FIN Message Rule Editor
Use this editor to set up the rules to select all incoming and outgoing flows so that they can be
pushed in the TRM flow as STP messages. This means that they do not get "stuck" waiting for

SWIFT Connectivity Guide

65

FIN Message Rule Editor

manual validation in the FIN Message Admin application. This may be crucial in the case of
CMM-related FIN messages (Source System in FIN Message Admin is CM).
The editor has the following fields:
Information

Description

ID

Identifies the rule being set up and is used to refer to the rule either from the FIN
Message flow or from the FIN Message Action Editor. More than one rule can have
the same ID: the condition between such rules is an "OR". This is similar to
transaction rules.
In the case of CMM:
•

FMFLO-FROM-CMM enables selection of all outgoing CMM payments and
messages.

•

FMFLO-TO-CMM enables selection of all incoming flows so that they are
imported STP into CMM.

Note: These rules are used in the TRM flow (finmessage.py). The name is hard

coded in finmessage.py therefore it is best to set them to the exact name
(unless you are modifying the finmessage python file). See 4.3.1 Rules
versus finmessage.py on page 68.

Rule

Rule name.

Comment

Free format comment field.

Message type

Contains the message type (MT type) number.

Operation

This field contains the function that is being performed on the messages (typically
NEW, AMEND or CANCEL), and is defined by the SWIFT standard.

Sender BIC

The BIC code of the sender of the message.

Receiver BIC

The BIC code of the receiver of the message.

Transaction Rule ID

The transaction rule to be used to match if a transaction number is present. If the
FIN message has a transaction number, then the transaction is checked to see if it
matches the transaction rule. If it matches, then the condition is considered to be
met.

Settlement Rule ID

The settlement rule to be used to match if a settlement ID is present. If the FIN
message has a settlement ID, then the settlement is checked to see if it matches
the settlement rule. If it matches, then the condition is considered to be met.

Source System

This identifies the module of the Suite from where a particular message was
initiated. The two most commonly used module codes are:

TRMSwift for TRM and CM for CMM. Entering CM for example will filter all FIN
messages going from CMM.
Target System

This identifies the Suite module where a message should go to. Possible values
depend on the configuration of ESIAdapter: see what is defined in ESIAdapter
Module Name Rule Editor and ESIAdapter FINSwift API Rule Editor.

CMM Bank ID

This enables filtering on banks and can come as a complement to the selection of
Sender or Receiver BIC.

CMM Payment Method

This enables the filtering on a particular Payment Method. This element is
particularly interesting to relate to bank-specific payment method that would
correspond to generic ones defined in CMM.

CMM Bank Account ID

This enables filtering of FIN messages for one account in particular. This is
intended primarily for incoming messages. Note that CMM already has very
flexible enrichment rules to serve that purpose.

CMM Currency

This relates to the currency available in CMM.

CMM Actual Amount From

This enables the creation of a rule, based on a minimum amount value.

CMM Actual Amount To

This enables the creation of a rule, based on a maximum amount value.

66

© Wall Street Systems IPH AB - Confidential

FIN Message Rule Editor

Information

Description

CMM Payment Priority

This corresponds to the urgent or normal flag put on the cash record constituting
the FIN message. Therefore it relates to the clearing priority (tag 23E of an MT101
for example) not to the priority (in block 2) with which the message is posted on
the SWIFT Network.

CMM On Behalf Of

This relates to CMM's On Behalf Of indicator. Available values are either Yes or No.
Yes indicates that the payment has been made on behalf of another entity.

CMM Aggregate Payment
Indicator

This enables the filtering of messages that contain payments resulting from
aggregated cash records. Available values are Yes or No.

CMM Intercompany

This relates to CMM's cash records 'intercompany' characteristic. It can be used to
filter(or not) intercompany payments from other releasable payments. Available
values are Yes or No.

CMM Originating System
Code

This relates to the process that has been creating the cash record constituting the
related FIN message. Examples of commonly used values are:
•

AP Import (meaning that cash record(s) were created from Account Payable

Import)
•

Man (meaning that the cash record(s) was created manually (compare with
CMM's Payment Factory - Capture - Enter Single Transaction)

If a field is empty, then it is not included in the rule. Each field that contains a value must match.
For the Transaction Rule ID and Settlement Rule ID, the underlying transaction or settlement (for
which the number or ID is saved in the FIN Message) is compared to see if it matches the rule. If
there is a rule that matches, but no Number or ID, then there is no match.

Selection lists
Most of the Information shown in the table above is associated with other relevant static data
elements that makes the user's choice easier. For example the Bank Account ID can be selected
from a list that also shows the Bank Account Number, the Bank ID and the Bank D and the Party ID.
These are called selection lists. A right click on the top of the column shows available elements that
can be added to that selection list. Note that these supplementary elements can also be filtered to
make a value's selection even easier.

When selecting Bank Account ID, other related static data elements are displayed as well so that it
is easier to choose from the Bank Account ID list the one that will be effectively used in the database
query.

SWIFT Connectivity Guide

67

FIN Message Action Editor

In this example, Number, Bank ID and Party ID can be filtered as well, in order to reduce the list of
available values further down.

4.3.1 Rules versus finmessage.py
In order for a FIN Message rule to be taken into account in the entity flow, it is necessary to make
sure this rule is referenced in the relevant python entity file: finmessage.py. This file is usually
found under …ws-suite\components\trm\share\python\entity-flow\

4.3.1.1 Straight through processing
Several rules are available at installation time.
FMFLO-STP, FMFLO-TO-CMM, FMFLO-TO-TRM, FMFLO-FROM-CMM, and FMFLO-FROM-TRM are
specifically dedicated to the Straight Through Processing of FIN messages in general: of FIN
messages coming and going to CMM or TRM.
The default configuration in finmessage.py is such that FIN messages are released or received
using STP. (Wall Street recommend that you leave the configuration in this state.) However, by
configuring the relevant rules and flow, you can hold this messages in a defined state for manual
review, amendment, or release.

4.3.1.2 finmessage.py
You should use serviced logs to find out which rule is applied. In finmessage.py, where several
rules have been set to match a particular event, the first rule that is matched (from the top of the
file) will be the one that is applied.

4.4 FIN Message Action Editor
Use this Editor to select the rules that identify the right FIN messages, and select the actions to be
performed on either the FIN Message header or FIN Message fields for identified messages. A set of
actions is delivered with the product, and additional actions can be implemented on site.

4.4.1 Rules
The main part of the FIN Format Action Editor has the following fields:
Information

Description

Rule ID

The ID of the rule that was set up in the FIN Message Rule Editor.

Not Rule ID

The ID of the Not rule that was set up in the FIN Message Rule Editor.

Group ID

The name of a group of rules. For each of the groups that have been defined in the
Group field, the rules are matched according to their priority. If all the required
conditions of the rule are met for any of the rules defined with the given rule id,
then the top part is considered to have been met. If this is the case, then the
changes (actions) indicated by the bottom half of the editor are made before the
next group can be considered.
Rules are first evaluated according to priority. Rules from different groups can
overlap in priority, but the top priority in each group is the rule that is met.
Processing is in group name order, so typically the group is prefixed by a number
to make sure the order is correct (e.g. 001-START, 014-CLIENTS, 044-END).

Priority

The priority of the selected rule which determines the order in which rules are
checked: lowest numbers have highest priority.

Rule Name

Name of the rule.

Not Rule Name

Name of the Not rule.

68

© Wall Street Systems IPH AB - Confidential

FIN Message Action Editor

4.4.2 Actions
The Actions tab is where you define one or more actions to perform when the rule is met. The actions
are performed in the order specifed by the order field.
The fields are:
Information
Action Type

Description
The type of action to be performed. These are:
ADD-PREFIX: takes Block, Order ID, Tag, Tag Option, FIN Sequence and Subfield
as search criteria. Adds a prefix to the first line (lowest Order ID) that was found
with the search criteria.
ADD-SUFFIX: takes Block, Order ID, Tag, Tag Option, FIN Sequence and Subfield
as search criteria. Adds a suffix to the last line (highest Order ID) that was found
with the search criteria.
REMOVE-FIELD: takes Block, Order ID, Tag, Tag Option, FIN Sequence and
Subfield as search criteria. Removes all lines that were found with the search
criteria.
SET-URGENT: sets the Urgent flag of the message header to Yes. If the value was
already "Yes", then the Yes value is kept. The Yes value results in the message
being sent with U3003 in header 2 (instead of N2020).
COPY-FIELD: takes Block, Order ID, Tag, Tag Option, FIN Sequence and Subfield
as search criteria. Makes a copy of all lines that match the search criteria, sets the
Order ID and Subfield of the copied lines according to Destination Order ID and
Destination Subfield values.
UPDATE-FIELD: takes Block, Order ID, Tag, Tag Option, FIN Sequence and
Subfield as search criteria. Keeps the first line of all lines found, the rest of the
lines are removed. The line that is kept is modified with values given by
parameters New Block, New Order ID, New Tag, New Tag Option, New FIN
Sequence, New Subfield, New Value, Modify and Hide Tag.
REPLACE-SENDER-RECEIVER: replaces the FIN message Sender BIC and
Receiver BIC with the values in the New Sender and New Receiver fields. If they
are blank then nothing is replaced. Useful when testing message content prior to
sending the message.
SEARCH-REPLACE-TEXT: Takes Block, Order ID, Tag, Tag Option, FIN Sequence
and Subfield as query criteria. Searches in all found fields the text given in the
"Search For" parameter and replaces it with the "Replace With" parameter. If
"Modify First Only" is supplied, only the first occurrence of text is replaced.

Note: The user should be aware that information might be lost if the search
criteria is not granular enough, since only the first line is kept and the rest is
removed.
ADD-FIELD: takes Destination Block, Destination Tag, Destination Tag Option,
Destination FIN Sequence and Destination Subfield as search criteria. Chooses the
first line that was found with the search criteria and add a new line either before
or after it according to the Destination Indicator value. The newly added line will
get its values updated with the parameters New Tag, New Tag Option, New Fin
Sequence, New Subfield and New Value.
MOVE-FIELD: takes Source Block, Source Order ID, Source Tag, Source Tag
Option, Source FIN Sequence and Source Subfield as search criteria to find the
lines to move. Destination Block, Destination Tag, Destination Tag Option,
Destination FIN Sequence and Destination Subfield are used as search criteria to
find the place where the source lines will be moved. Similar to ADD-FIELD,
Destination Indicator is used to decide if the movement will be before or after the
destination line.
FORMAT-TEXT: takes Block, Order ID, Tag, Tag Option, FIN Sequence and
Subfield as search criteria. Concatenates the text of matched lines, replacing the
carriage return character with a space character. The resulting string is distributed
over the lines based on the parameters Max Characters per Line, Max Number of
Lines, First Line Prefix and Remaining Lines Prefix. Having the parameter Word
Wrap set to NO would indicate that a word can be split between two lines.

SWIFT Connectivity Guide

69

FIN Message Action Editor

Information

Description

Order

If there is more than one action associated with this rule, the Order number
determines the order in which the actions are performed.

Remaining fields

The fields below the Order field change their function, depending on the selected
Action Type.

70

© Wall Street Systems IPH AB - Confidential

Chapter 5

SWIFTnet Accord

5.1 Confirmation matching
SWIFTNet Accord is a service provided by SWIFT (on the SWIFT network), where messages are
copied to the Accord service for any business entity that subscribes to the service. SWIFTNet Accord
then either performs the confirmation matching automatically, or allows users to perform manual
matching. TRM retrieves the matching status from Accord and updates itself with the relevant
information.
The matching status is fetched from SWIFTNet Accord for confirmation messages that have been
sent over the SWIFT network and the FIN Message and correspondent transaction in TRM are
updated with the matching status.

•

The fetching of the matching status according to the SWIFTNet Accord API provided by SWIFT is
performed by the Enterprise Swift Integration Adapter (ESIAdapter).

•

The transaction in TRM is updated by performing a (transaction flow) action, typically pushing it
forward in the flow if it has been matched successfully, or rejecting it in the flow if it has failed
matching.

•

The FIN Message in TRM is also updated by performing a (FIN Message flow) action, typically
pushing it forward/backwards in the flow. Only confirmation (FIN) messages that have been sent
via the FIN Message Manager can be automatically updated by ESIAdapter.

5.1.1 Accord simulator
To simulate receiving a confirmation matching status coming from Accord, the following command
can be used:
python %FK_HOME%\bin\match-simulator.py -a -r  -b

Where:
-a

Required only in a Windows environment

-r

 is the value from the reference field in the Fin Message Manager, normally
-.

-b

 is one of three match statuses (case insensitive).

The FIN message is then updated with the status and moved in the flow, and the corresponding
transaction is potentially also moved in the flow.

SWIFT Connectivity Guide

71

Confirmation matching

5.1.2 Polling the Accord API

Q01

TRM Matcher

Transaction
DoAction

Q02

Uses transaction number to find other
messages and determine matching status.

Entity
DoAction

FIN Message Admin
Processing
driven by the
Flow and FIN
Message
Admin
Q03

ESI Adapter

Q04

Transaction Admin

Match
Reconciliator

Uses references
to find the IDs.
InterAct

SAG
(SWIFT Alliance
Gateway)

SWIFT Network
including
Accord

Queue names:
Q01 $(wss.env.name).match.checker

SWIFT System
Q02 $(wss.env.name).match.transaction
Q03 $(wss.env.name).match.finmessage
Q04 $(wss.env.name).esiadapter.match

ESIadapter compiles a query for the BIC in question according to the ESICRM Editor, and sends the
request for information to Accord. This request (query) and matching status (query result) are
based on the API definition. Once a matching status is returned from Accord, it is made available for
further processing on an incoming queue (Q04). At this point, the references in the matching status
are the references used in the FIN messages that had previously been sent to SWIFT.

72

© Wall Street Systems IPH AB - Confidential

Confirmation matching

Note that there can be references for more than one confirmation message in the matching status
(result). Different confirmation messages represented by the references within the matching status
can also have different matching status outcomes (matched, unmatched, or mismatched).

5.1.3 Reconciling of results
For each of the references to confirmation messages within the matching status, the Match
Reconciliator service looks up the FINMessage to determine the FIN Message id corresponding to the
confirmation message. It is assumed the FIN message ids are unique.
Each of the FIN Messages must be updated in a specific way, based on its match status. This is
done by making each FIN Message id (on Q03) available for further processing along with an entity
action to perform (based on the matching outcome) and a comment in case of errors.

5.1.4 Updating the FIN Message
For each of the FIN Messages to be updated, a FIN Message id, an action to perform (based on the
matching outcome) and a failure comment (if applicable) are provided to an EntityDoAction
(serviced) service. This service updates the status_description column on the FINMessage and
call the action (as defined in the FIN Message flow) via the entity broker.
A typical FIN Message flow setup includes Sent, Matched, and Mismatched states. Based on the
matching status received for the particular confirmation message, the FIN Message flow facilitates
the FIN Message’s movement between these different states. Further processing on the transaction
is triggered for these state transitions.

•

Sent indicates that the FIN Message has successfully been sent over the FIN network and all
acknowledgements have been received. The matching status is still unmatched (i.e. it is not yet
considered matched, and there are no known problems regarding the matching). In Accord
terms, this is for Deal Status "P".

•

Matched indicates that a matching status has been received and that we consider the FIN
Message matched. Basically it mean we and the counterparty agree on the details of the deal
(to the level defined by the Accord matching rules). In Accord terms, this is for Deal Status "M"
and "A".

•

Mismatched indicates that we know there is a problem regarding the matching. Something
needs to be done to ensure that we and the counterparty agree on the details of the deal. In
Accord terms, this is for Deal Status "U", "S", and "D".

It is also possible to manually trigger the subsequent processing by manually accepting or rejecting
the FIN Message from within FIN Message Admin.

5.1.5 Multiple messages
Where there are multiple confirmation messages for a single transaction, the transaction is not
considered agreed with the counterparty until all confirmation messages have been matched. The
TRMMatcher component receives the FIN Message id for each of the confirmation messages when
the match status is changed (on Q01).

•

If status is changed to Mismatched, then the transaction is considered mismatched. To achieve
this, the transaction number is passed on for further processing along with the fact that the
match has failed.

•

If status is changed to Matched and this is the last confirmation message for which a matched
status is needed (i.e. was outstanding) and all other confirmation messages were considered
matched, then the transaction number is passed on for further processing along with the fact
that the match has succeeded.

To determine if this is the last outstanding message and all other messages are considered
matched, the FIN Message id is used to look up all the transaction numbers. The transaction
number is then used to look up all outgoing FIN Messages and their match status is checked. When
multiple messages are linked, only the last message is considered. For transactions with multiple
legs (such as FX Swaps having two MT300 messages), both legs are checked.

SWIFT Connectivity Guide

73

Confirmation matching

Once again the matching status of all the FIN Messages for the transaction is used for further
processing to know which transaction action to call (on Q02).

5.1.6 Updating the transaction
For each of t he transactions where the match status is changed, the transaction number, the action
to perform (based on the outcome of the match status for all confirmation messages for the
transaction) and the comment (error message) are received by the TransactionDoAction (serviced)
service on Q02. This service updates a comment field with the error message (if there is one) and
calls the transaction action. The action taken is configurable on site by changing the transaction
flow definition. The name of the action is determined by the previous service and is limited to:

•

SH-MATCH-ACCEPT: This indicates that the confirmation message was successfully matched
with a counterparty message. This would typically result in the transaction being pushed
forward in the flow.

•

SH-MATCH-REJECT: This indicates that the confirmation message was not matched and
considered incorrect. This would typically result in the transaction being rejected in the flow.

•

SH-MATCH-RESET: This indicates the status of the message is unkown. This would typically
result in no action being taken, but if a transaction was previous considered matched, it should
no longer be considered matched.

The action can result in the transaction being pushed forward or backward in the flow, or in a status
being set.

5.1.7 Backdated trades and ESIAdapter
When polling for Matching status updates from SWIFTNet Accord, ESIAdapter takes into
consideration backdated deals entered within the last ten days.

74

© Wall Street Systems IPH AB - Confidential

Chapter 6

SWIFT package overview

TRMSwift is an Enterprise Application Integration (EAI) tool based on messaging technology. This
tool provides a highly customizable, powerful and flexible interface for exchanging business events
with your financial counterparties through dedicated network and system connections.
TRMSwift is part of the WSS connectivity product solutions and enables you to interface your
financial applications with banks, settlement and payment systems, as well as with your proprietary
applications. The TRMSwift solution also operates with the comKIT API, enabling you to access and
manipulate TRM data and business logic.
TRMSwift includes various packages which add new functionality to the overall framework. The
SWIFT package is used to add SWIFT messaging capabilities. This includes both messages that are
sent to or received from the SWIFT network. The SWIFT package contains configurations for:

•

Formatting

•

Internal routing

•

Enriching data received (generally from TRM)

•

External routing to various adapters

6.1 Data Integration
TRMSwift automatically decides if a transaction should generate a new message or whether an
adjustment should be made to a previous operation (AMEND, CANCEL or ROLLOVER). TRMSwift
stores a list of transactions that have entered the system and compares each new incoming
transaction with the stored transactions. To make a decision to amend, cancel, or generate a
rollover you must have a copy of the previous message in the TRMSwift database.

Note: Transactions that have been settled manually and migrated into the TRMSwift database

should be sent back in the TRM transaction flow (the state is decided locally). When these
transactions re-enter TRMSwift they generate a dummy history record and a dummy
SWIFT message. These dummy records do not impact limit management or accounting
functionality in TRM.

6.2 SWIFT message scenarios
The following sections list the scenarios in which specific SWIFT messages are transmitted.

SWIFT Connectivity Guide

75

SWIFT message scenarios

6.2.1 Money market and foreign exchange confirmations
Instrument
Type

Trade Date

FX Spot

Value
Date

Change
Deal

Change
Counterparty

Cancellation

Matching

MT300

Amended
MT300

Cancel
previous
message and
New MT300

MT392 or
MT300 with a
CANC in field
22A

Accord

FX NOF

MT300
(fixing)

Amended
MT300

Cancel
previous
message and
New MT300

MT392 or
MT300 with a
CANC in field
22A

Accord

FX Forward

MT300

Amended
MT300

Cancel
previous
message and
New MT300

MT392 or
MT300 with a
CANC in field
22A

Accord

FX Swap

MT300 x2

Amended
MT300x2

Cancel
previous
message and
(one per leg)
New MT300 x 2

2 x MT392

Accord

Amended
MT305

Cancel
previous
message and
New MT305

MT392 or
MT305 with a
CANC in field
22A

Accord

Amended
MT320

Cancel
previous
message and
New MT320

MT392 or
MT320 with a
CANC in field
22A

Accord

Amended
MT320

Cancel
previous
message and
New MT320

MT392 or
MT320 with a
CANC in field
22A

Accord

Amended
MT330

Cancel
previous
message and
NEW MT330

MT330 with
CANC in field
22A

Accord

Amended
MT340 /
MT341

Cancel
previous
message and
New MT340 /
MT341

MT392 or
MT340 / MT341
with a CANC in
field 22A

Manual

Cancel previous
message and
New MT518

Manual

Rollover

(One per
leg)

(One per leg) or
2 x MT300 (one
per leg) with a
CANC in field
22A

FX OTC
Option

MT305

Fixed
Deposit

MT320

Floating
Deposit

MT320

BIS/FED
cash
transfer

MT330

FRA

MT340

Bond or
Repo

MT518

IR Swap

Fixing Date: MT362

BIS Medium
Term
Instrument

MT599

MT592

Manual

BIS
Discount
FIXBIS

MT599

MT592

Manual

76

MT320

MT320
(fixing)

MT341
(upon
fixing)

Cancel
previous
message
and New
MT518

Accord

© Wall Street Systems IPH AB - Confidential

SWIFT message scenarios

Instrument
Type
Gold
Deposit
Provisional
or Final
confirmatio
n

Trade Date
MT699

Value
Date

Rollover

Change
Deal

Change
Counterparty

MT699

Cancellation

Matching

MT692

6.2.2 Payments
Payment / Value
Date

Cancellation

Comments

Payment of Cash (to a non
financial institution)

MT103

MT192

Generally used in conjunction with an
MT202.

Transfer for own account

MT200

MT292

Payment of Cash

MT202

MT292

Payment of Cash

MT203

MT292

Receipt of Cash

MT210

MT292

Interest Payment

MT350

MT350 (with CANC
in field 22A)

Payment of precious metal.

MT604

MT692

The precious metal must be
configured as the currency of the
transaction.

Event

Merged within TRMSwift by merging
two MT202 or an MT202 and MT203.
Can also be split within the Message
Monitor.

6.2.3 Private client confirmation
Event

Payment / Value
Date

Cancellation

Comments

Debit of private client

MT900

MT992

Based on payments generated in
Settlement Manager and not on Call
Money / Call Account.

Credit of private client

MT910

MT992

Based on payments generated in
Settlement Manager and not on Call
Money / Call Account.

SWIFT Connectivity Guide

77

SWIFT message scenarios

6.2.4 Security movements
Instrument
Type

Value
Date

Repo

MT543

Rollover /
Coupon
Payment

Margin

MT210 or
MT202

Amendment

Cancellation

MT540

MT292

MT543 CANC in field 23G

Or MT542

MT54n CANC if
field 23G

MT292

Call

MT541
NEWM

MT54n NEWM
MT210 or MT202

Repo-Reverse

MT541

MT202 or
MT210

MT540

MT292

MT541 CANC if field 23G

Or MT542

MT54n CANC if
field 23G

MT292

MT543
NEWM

MT54n NEWM
MT202 or MT210

Collateral
Substitution

MT541
MT543

MT54n CANC if
field 23G

MT541 CANC in field 23G

MT54n NEWM

MT292

MT543 CANC in field 23G

Buy Security

MT540

MT292

MT540 CANC in field 23G

FoP

MT202

MT540 CANC if
field 23G

MT292

MT540 NEWM
MT202
Sell Security

MT542

MT292

MT542 CANC in field 23G

FoP

MT210

MT542 CANC if
field 23G

MT292

MT542 NEWM
MT210
Buy Security

MT541

DvP

MT541 CANC if
field 23G

MT541 CANC in field 23G

M7T 541 NEWM
Sell Security

MT543

DvP

MT543 CANC if
field 23G

MT543 CANC in field 23G

MT543 NEWM

6.2.5 Statement messages
Received
Message

Action

Comments

MT535

Insert into custody balance statement for
reconciliation in TRM.

This message is received from SWIFT.
Note that limited fields are used to create
the transaction.

MT950

Insert into state of accounts for reconciliation in
TRM

This message is received from SWIFT.

78

© Wall Street Systems IPH AB - Confidential

SWIFT message details

6.2.6 Transaction Generation
Received
Message
MT515

Action

Comments

Create a Treasury Bill or Cash movement
transactions based on the data in the SWIFT
message.

This message is received from SWIFT.
Note that limited fields are used to create
the transaction.

6.3 SWIFT message details
This section describes the supported SWIFT messages. (For further information, please see the
SWIFT documentation.)

6.3.1 MT103 - Single Customer Credit Transfer
The MT103 message is used to exchange single customer credit transfers. It can be used in 3
different ways:

•

The message can be sent by itself to your own bank and follows up the chain to the beneficiary
bank.

•

The message can be sent to your counterparty’s bank in conjunction with sending an MT202 to
your own bank. This is achieved by using the transfer method SWIFT-MT103202.

•

The message can be sent to the bank of your counterparty’s bank in conjunction with sending an
MT202 to your own bank. This is achieved by using the transfer method SWIFT-MT103202-AWI.

In each of the cases mentioned above, the account information is changed correspondingly. You
should note the following settlement transfer methods.
Settlement Transfer
Method

Settlement Chain

Conditions

Message

Sender

Receiver

MT103

Our Bank

Our Bank = Client Bank

MT103

Us

Our Bank

Client Bank

(This is not
mandatory.)

Our Bank

Our Bank has an
account at the Client
Bank

MT103

Us

Our Bank

MT103

Us

MT202

Us

Client’s
Correspondent
Bank

MT103

Client Bank

(This is not
mandatory.)
MT103202AWI

Our Bank
Client’s
Correspondent
Bank

Our Bank has an
account at the Client’s
Correspondent Bank

Our Bank

Client Bank
MT103202

Our Bank
Client Bank

MT103202

Our Bank
Client’s
Correspondent
Bank

There is no relation
between Our Bank and
the Client Bank

MT103

Us

Client Bank

MT202

Us

Our Bank

There is no relationship
between Our Bank and
the Client’s
Correspondent Bank.

MT103

Us

Client Bank

MT202

Us

Our Bank

Client Bank

SWIFT Connectivity Guide

79

SWIFT message details

Settlement Transfer
Method

Settlement Chain

Conditions

Message

Sender

Receiver

MT103202

Our Bank

There is no relationship
between Our
Correspondent Bank
and the Client’s
Correspondent Bank.

MT103

Us

Client Bank

MT202

Us

Our Bank

There is no relationship
between Our
Correspondent Bank
and the Client’s
Correspondent Bank.

MT103

Us

Client Bank

MT202

Us

Our Bank

Our Correspondent
Bank
Client’s
Correspondent
Bank
Client Bank
MT103202

Our Bank
Our Correspondent
Bank
Client’s
Correspondent
Bank
Client Bank

6.3.2 MT192 - Request for Cancellation
This is a normal cancellation message for any MT1xx message. When the cancelling message is
sent, the fields from the original message are placed within the cancelling message. The related
reference is determined by the reference number of the previously sent message.

6.3.3 MT200 - Financial Institution Transfer for its Own Account
The MT200 is used to transfer funds (for your own account) from one bank to another. In such a
case, the portfolio owner is the counterpart. The message is sent from you to your bank asking to
transfer funds to your other bank.

6.3.4 MT202 - General Financial Institution Transfer
The MT202 is used to transfer funds to another institution. The message is sent from you to your
bank asking to transfer funds to your counterpart via all banks in between.
Various fields change depending on whether this message is sent alone or in conjunction with the
MT103 message.

6.3.5 MT203 - Multiple General Financial Institution Transfer
The MT203 message is created by merging various MT202 or MT203 messages. You do this using
the TRMSwift Message Merger functionality. Messages can also be split within the Sequence panel of
the Message Monitor. Note that certain criteria must be matched before any messages can be
merged. For each message that is merged, a new sequence is created, up to a maximum of 10
sequences.
Default configuration allows only MT203 messages to be merged. Merging with MT202 can be
enabled.

6.3.6 MT210 - Notice to Receive
The MT210 message is sent by you to your bank to inform it that you will be receiving funds. It is
also possible to merge various MT210 messages into a single MT210. Note that there is a maximum
of 10 sequences.
To enable automatic or manual merging of this message type, there has to be a decider for
MessageMerger updated in the WorkflowController element.

80

© Wall Street Systems IPH AB - Confidential

SWIFT message details

6.3.7 MT292 - Request for Cancellation
This is a normal cancellation message for any MT2xx message. When the cancelling message is
sent, the fields from the original message are placed within the cancelling message. The related
reference is determined by the reference number of the previously sent message.

6.3.8 MT300 - Foreign Exchange Confirmation
The MT300 confirmation message is to your counterparty to confirm the details of an FX transaction.
It can be used for Spot, Forward, Swaps, or non-deliverable Forward (Confirmation or Fixing). For a
Swap transaction, two MT300 messages are generated.
An MT300 message can also be used to amend the details of a previously sent MT300 message.
Instead of sending an amend message, both a cancel and a new message may also be sent.
Generally, the cancellation message is sent when the transaction is rejected back to the TRM
workflow and the new message is sent when it is accepted again.
An MT300 message can also be used to cancel the confirmation of a previously sent MT300
message.
Optional sequences C (Optional General Information) & D (Split Settlement Details) are currently
not supported.
Confirmation matching can be done with SWIFTnet Accord.

6.3.9 MT305 - Foreign Currency Option Confirmation
The MT305 confirmation message is sent from you to your counterpart to confirm the details of an
FX Option transaction. Cancellations and amendments work in a similar way to the MT300
messages. Confirmation matching can be done with SWIFTnet Accord.

6.3.10 MT320 - Fixed Loan/Deposit Confirmation
The MT320 confirmation message is sent from you to your counterpart to confirm the details of an
FX Deposit or Loan transaction. Cancellation and amendments work in a similar way to the MT300
messages.
Option sequences G (Tax Information) and H (Additional Information) are currently not supported.
This message is also sent for rollovers of FX Deposit or Loan transactions or for the fixing of a
floating-rate loan.
Confirmation matching can be done with SWIFTnet Accord.

6.3.11 MT330 - Call/Notice Loan/Deposit Confirmation
The MT330 confirmation message is sent to your counterpart to confirm agreed changes of a
Load/Deposit. The confirmation is sent in order to confirm changes to the principal amount.
Cancellation and amendments work in a similar way to the MT300 messages.
Optional sequences E (Settlement Instructions for Interests Payable by Party A), F (Settlement
Instructions for Interests Payable by Party B), G (Tax Information) and H (Additional Information)
are currently not supported.
Confirmation matching can be done with SWIFTnet Accord.

6.3.12 MT340 - Forward Rate Agreement Confirmation
The MT340 confirmation message is sent to your counterpart to confirm the details of a Forward
Rate Agreement (FRA) transaction. Cancellation and amendments work in a similar way to the
MT300 messages.
Optional sequence E (Additional Information) currently only supports the 72 (Sender to Receiver
Information) field.
Confirmation matching can be done with SWIFTnet Accord.

SWIFT Connectivity Guide

81

SWIFT message details

6.3.13 MT341 - Forward Rate Agreement Settlement Confirmation
The MT341 confirmation message is sent from you to your counterpart to confirm the fixing of the
rate of a Forward Rate Agreement (FRA) transaction. This message should only be sent once the
corresponding MT340 message has been sent. This can be ensured by placing it in the correct place
in the TRM workflow. Cancellation and amendments work in a similar way to the MT300 messages.
Confirmation matching can be done with SWIFTnet Accord.

6.3.14 MT350 - Advice of Loan/Deposit Interest Payment
You send an MT350 message to your bank informing them that an interest amount has been paid to
the account of the beneficiary with the receiving agent specified in the message. The message is
based on a payment.

6.3.15 MT362 - Interest Rate Reset/Advice of Payment
NEW and AMEND confirmation messages are sent from transactions with one leg floating and one
leg fixed. With the default setup, the instrument group of the instrument used on the transaction
must be /IR/SWAP/IR. This setup can be changed by updating the property irs.instrument.group
in %FK_HOME%\etc\trmswift\package\SWIFT\swift.properties.
Confirmation matching can be done with SWIFTnet Accord.

6.3.16 MT392 - Request for Cancellation
This is a normal cancellation message for any MT3xx message. When the cancelling message is
sent, the fields from the original message are placed within the cancelling message. The related
reference is determined by the reference number of the previously sent message.
Generally the MT392 message is not used. Instead, the original MT3xx message is cancelled by
sending a similar message (of the same MT type), using the correct operation code (typically CANC).

6.3.17 MT395 - Queries
SWIFT standards scope definition: It is used to request information or clarification relating to a
previous SWIFT or non-SWIFT message or to one or more transactions contained therein.
Message text can be entered in FIN Message Admin.

6.3.18 MT396 - Answers
SWIFT standards scope definition: It is used to respond to an MT 395 Queries or MT 392 Request for
Cancellation and other messages where no specific message type has been provided for the
response.
Message text can be entered in FIN Message Admin.

6.3.19 MT399 - Free Format Messages
SWIFT standards scope definition: This message type is used by financial institutions to send or
receive information for which another message type is not applicable.
Message text can be entered in FIN Message Admin.

6.3.20 MT515 - Client Confirmation of Purchase or Sale
The MT515 message is received from a counterparty and is used to create either a Treasury Bill or
Cash Movement transaction in TRM. Details are based on the actual content of the message.
Additional configuration in TRM is required to define the portfolio, counterparty, and instrument
used in the transaction.

82

© Wall Street Systems IPH AB - Confidential

SWIFT message details

6.3.21 MT518 - Market-Side Securities Trade Confirmation
The MT518 message is sent to a counterparty to confirm details of a bond or repo transaction on the
opening date. For a Buy/Sell Back or Sell/Buy Back transaction there are two messages created.
Amendments to the trade cancel the original message and send a new one.

6.3.22 MT535 Statement of Holdings
This message is received from your custodian to indicate the movements on a particular custody
account. The message can be broken into several balances per instrument before being inserted in
TRM for reconciliation. Sequencing of the message received in multiple pages is done in ESIAdapter,
see 2.1.5 Message sequencing on page 22.

6.3.23 MT540 - Receive Free
The MT540 message is sent from you to your bank or custodian to advise of the receipt of financial
instruments free of payment, physically or by book-entry received from your counterparty. ISIN or
CUSIP security identifiers (as configured in the Instrument Editor) can be used to identify the
instrument.
Place of Settlement (PSET in E1) is supported by entering the corresponding data in Client Editor.
Optional sequence F (Other Parties) is currently not supported. Pre-advice of receipt (Function of
message equals PREA) is currently not supported.

6.3.24 MT541 - Receive Against Payment
The MT541 message is sent from you to your bank or custodian to advise of the receipt of financial
instruments against payment, physically or by book-entry received from your counterparty. ISIN or
CUSIP security identifiers (as configured in the Instrument Editor) can be used to identify the
instrument.
Place of Settlement (PSET in E1) is supported by entering the corresponding data in Client Editor.
Optional sequence F (Other Parties) is currently not supported. Pre-advice of receipt (Function of
message equals PREA) is currently not supported.

6.3.25 MT542 - Deliver Free
The MT542 message is sent from you to your bank or custodian to order the delivery of financial
instruments free of payment, physically or by book-entry received from your counterparty. ISIN or
CUSIP security identifiers (as configured in the Instrument Editor) can be used to identify the
instrument.
Place of Settlement (PSET in E1) is supported by entering the corresponding data in Client Editor.
Optional sequence F (Other Parties) is currently not supported. Pre-advice of delivery (Function of
message equals PREA) is currently not supported.

6.3.26 MT543 - Delivery Against Payment
The MT542 message is sent from you to your bank/custodian to instruct the delivery of financial
instruments against payment, physically or by book-entry received to your counterparty. ISIN or
CUSIP security identifiers (as configured in the Instrument Editor) can be used to identify the
instrument.
Place of Settlement (PSET in E1) is supported by entering the corresponding data in Client Editor.
Optional sequence F (Other Parties) is currently not supported. Pre-advice of delivery (Function of
message equals PREA) is currently not supported.

SWIFT Connectivity Guide

83

SWIFT message details

6.3.27 MT592 - Request for Cancellation
This is a normal cancellation message for any MT5xx message. When the cancelling message is
sent, the fields from the original message are placed within the cancelling message. The related
reference is determined by the reference number of the previously sent message.
Generally the MT592 message is not used. Instead, the original message is cancelled by sending a
similar message (of the same MT type), using the correct type of operation code.

6.3.28 MT599 - Free Format Message
This message is sent from you to your counterpart to confirm the details of the following trades:

•

Buying or Selling of a US Bank of International Settlements (BIS) Treasury Bill.

•

Buying or Selling of Medium Term interest notes issued by BIS.

The message can either be sent as a NEW or an AMEND message. It is always cancelled by using a
MT592 message.

6.3.29 MT604 - Precious Metal Transfer/Delivery Order
This message is sent from you to the Bank of England. It instructs unallocated gold to be delivered
to your counterpart.
It is also possible to merge various MT604 messages into a single MT604. To enable automatic or
manual merging of this message type, there has to be a decider for MessageMerger updated in the
WorkflowController element.
The message cannot be amended once sent. You should cancel it using a MT692 message and send
a new MT604 message.

6.3.30 MT692 - Request for Cancellation
This is a normal cancellation message for any MT6xx message. When the cancelling message is
sent, the fields from the original message are placed within the cancelling message. The related
reference is determined by the reference number of the previously sent message.

6.3.31 MT699 - Free Format Message
This message is sent to your counterpart to confirm a gold deposit provisional confirmation, a gold
deposit final confirmation, or a gold deposit rollover confirmation.

6.3.32 MT900 - Confirmation of Debit
The MT900 message is sent to your counterpart to confirm a debit of their account. This is used in
conjunction with having private clients as portfolio owners for which you service an account
(generally used with TRM). It is based on a payment as generated in the Settlement Manager and
not on the Call Account/Call Money functionality. To cancel such a message an MT992 must be used.

6.3.33 MT910 - Confirmation of Credit
The MT900 message is sent to your counterpart to confirm a credit of their account. This is used in
conjunction with having private clients as portfolio owners for which you service an account
(generally used with TRM). It is based on a payment as generated in the Settlement Manager and
not on the Call Account / Call Money functionality. To cancel such a message an MT992 must be
used.

6.3.34 MT950 - Statement Message
The MT950 message is received from your bank to indicate the cash movements on a particular
account. The message is broken up into various movements before being inserted in TRM for
reconciliation.

84

© Wall Street Systems IPH AB - Confidential

SWIFT message details

6.3.35 MT992 - Request for Cancellation
This is a normal cancellation message for any MT9xx message. When the cancelling message is
sent, the fields from the original message are placed within the cancelling message. The related
reference is determined by the reference number of the previously sent message.

SWIFT Connectivity Guide

85

SWIFT message details

86

© Wall Street Systems IPH AB - Confidential

Chapter 7

SWIFT package configuration

This chapter provides technical information on how to install and configure the SWIFT package.

7.1 Configuring swift.properties
You need to set additional properties, based on the SWIFT messages you are using. These
properties are listed in the following sections.

7.1.1 MT515
When using the MT515 message to create transactions in TRM, you must specify the following
properties:
Property name

Description

MT515.incoming.cp_client_id

The client id of the counterpart for which this should be done. The
transaction will be created with this client id.

MT515.incoming.market_id

The market id of the transaction to create.

MT515.incoming.repo.instrumentId

ID of the instrument that is used for the transaction creation.

MT515.incoming.repo.portfolioId

ID of the portfolio in which the transaction is created.

7.2 Pre-defined confirmation adapters
The following sections list all the TRMSwift adapters used to obtain confirmation or payment
business events from TRM. All these adapters use the comkit.command.parameters property as
defined in the general.properties file.

SWIFT Connectivity Guide

87

Pre-defined confirmation adapters

7.2.1 FXConfirmation
Adapter

Type

Property

FXSpotForward

Pickup Mode

SH-FX-SPOT-FWD

Reference Mode

SH-HOLD

MT type

MT300

Pickup Mode

SH-FX-SPOT-NDF

Reference Mode

SH-HOLD

MT type

MT300

Pickup Mode

SH-FX-SWAP

Reference Mode

SH-HOLD

MT type

MT300 (two legs)

Pickup Mode

SH-FX-OPTION

Reference Mode

SH-HOLD

MT Type

MT305

Adapter

Type

Property

IRLOAN

Pickup Mode

SH-IR-LOAN

Reference Mode

SH-HOLD

MT type

MT320

Pickup Mode

SH-IR-FRA

Reference Mode

SH-HOLD

MT type

MT340

Pickup Mode

SH-IR-BILL-BIS

Reference Mode

SH-HOLD

MT type

MT599 (MT599-FIXBIS)

Pickup Mode

SH-IR-MTN-BIS

Reference Mode

SH-HOLD

MT type

MT599 (MT599-MTIBIS)

FXSpotForwardNDF

FXSwap

FXOption

7.2.2 MMConfirmation

IRFRA

IRBILLBIS

IRMTNBIS

7.2.3 BAConfirmation
7.2.4 FixingConfirmation

88

© Wall Street Systems IPH AB - Confidential

Instrument groups

7.2.5 CancelConfirmation
Adapter

Type

Property

CancelConfirmation

Pickup Mode

SH-CANC-GET

Reference Mode

SH-CANC-HOLD

MT type

MT392 or MT3xx
(with CANC in field 22A)

Adapter

Type

Property

SettlementQueueFactory - MT1

Rule

SFLO-SWIFT-MT1

MT type

MT103

Rule

SFLO-SWIFT-MT2

MT type

MT200, MT202, MT203 or MT210

Rule

SFLO-SWIFT-MT3

MT type

MT350

Rule

SFLO-SWIFT-MT5

MT type

MT540-MT543

Rule

SFLO-SWIFT-MT6

MT type

MT604

Pickup Mode

8SH-CANCEL

Reference Mode

9SH-CANCELED

Transfer type

SH-SWIFT%

MT type

MTn92
(the same as the transfer type) or
MT54n
(with a CANC - if cancelling an MT54n message)

7.2.6 Payments

SettlementQueueFactory - MT2

SettlementQueueFactory - MT3

SettlementQueueFactory - MT5

SettlementQueueFactory - MT6

CancelPayment

7.3 Instrument groups
The two properties below are used as part of the query parameters for the feeders
FXSpotForwardNDF and IRFRAFixingConfirmation to ensure that transactions of the correct
instrument group are retrieved.
They need to be set only when the client installation does not use the standardized instrument group
hierarchy supplied with the Factory setup. (This is what the default values supplied are based on.)
Property name

Description

fxforwardndf.instrument.group

Set to the common instrument group for NDF FX Forwards (as
seen in the Instrument Editor).

iffra.instrument.group

Set to the common instrument group for FRAs (as seen in the
Instrument Editor).

SWIFT Connectivity Guide

89

Instrument groups

90

© Wall Street Systems IPH AB - Confidential

Chapter 8

TRMSwift and CMM setup after
installation

8.1 Introduction
TRMSwift and WebSuite are installed with Wallstreet Suite Installer. By default, the Suite Installer
sets up environment variables and tables.

8.2 Setting up TRMSwift environment variables
These variables are defined with SuiteInstaller framework in file
/envs//etc/environment/parts/60_trmswift.bat/.sh:
The values are as follows:
TRMSWIFT_USER=
TRMSWIFT_PASSWORD=
TRMSWIFT_COMKIT_SERVICE=
TRMSWIFT_COMPONENT=

8.3 Updating tables
Update the tables before first use of TRMSwift or after a change in configuration. Open a Suite
Installer Shell, (/envs//bin/xxx-shell.bat/.sh) and enter the
following command:
UNIX:
rc.trmswift update
Windows:
bin\trmswift.bat update
This command can also process a single subdirectory within the whole configuration tree:
trmswift update 
Example: rc.trmswift update FAX

8.3.1 Visualizing the configuration
Use the command trmswift dump IKITSetupElement to log the content of the IKITSetupElement
configuration table. For more information see 11.3 Displaying the current TRMSwift configuration on
page 123.

SWIFT Connectivity Guide

91

Setting up the CMM environment

8.4 Setting up the CMM environment
The Cash Management (CMM) part of WebSuite must be configured to communicate with the
Enterprise Swift Integration Adapter (ESIAdapter).

8.4.1 Technical setup
1. Check that the file actformatmapping.xml is correct for the type of file for export or import.
2. Check in poststatushandling.xml. This is used for TIMEOUT and REJECTS.
3. Check the swift-adaptor-jmsconfig.xml file. This file tells CMM where ActiveMQ is located,
and the queue that CMM should use for communicating with ESIAdapter:







jms.broker.host=10.35.0.130


jms.broker.port=20460


jms.broker.url=tcp://${jms.broker.host}:${jms.broker.port}?trace=true



jms.send.queue=${wss.env.name}.esiadapter.in



jms.receive.queue=${wss.env.name}.esiadapter.cm





4. When the CMM configuration for ESIAdapter is finished, restart WebSuite.
Once the technical setup is done, set up of the communication protocol and the interchange.

92

© Wall Street Systems IPH AB - Confidential

Setting up the CMM environment

8.4.2 Communication protocol and interchange setup
8.4.2.1 Communication protocol for FIN

8.4.2.1.1 Outbound FIN format messages from CMM to ESIAdapter
Message types:

•

MT101 - Payments

•

MT104 - Direct Debits

•

MT210 - Preadvice

ESIAdapter does not replace block 1 and block 2 headers for messages generated from CMM. CMM
sends the complete FIN message to ESIAdapter including blocks 1 and 2. This in turn means the
Test BIC code in ESICRM is not used at all.
For FIN messages leaving CMM there are three critical configuration items.

Configuration in the Suite
The BIC codes (also known as "SWIFT Codes") must be configured for either Production or Test.
There is no full Suite support for switching between the two.
This means that

•

The Swift Code setup in the Client Editor must be configured once for testing with the test BIC
codes, and reconfigured again when the client moves to production with the production BIC
codes.

•

The BIC codes must be configured for both the receiving Bank and the sending entity.

Configuration in ESICRM
ESICRM needs to be configured with exactly the same BIC code. In ESICRM, if the setup is for a test
environment, then the BIC code in ESICRM needs to be the Test BIC code for both the BIC Code and
the Test BIC Code.

SWIFT Connectivity Guide

93

Setting up the CMM environment

Client Editor Showing a sample BIC code for the receiver:.

Corresponding ESICRM showing the BIC code for the receiver:

8.4.2.2 Communication protocol for FileAct

8.4.2.2.1 Outbound FileAct format messages from CMM to ESIAdapter
Message types: non-SWIFT messages, for example AFB160.
For FileAct messages leaving CMM, there are three important fields that ESIAdapter uses to
translate the internal message to one acceptable for FileAct. This means determining:

•

Sender and Receiver Distinguished Names (DNs)

•

Request Type Name

•

File Information

which are then placed on the outgoing message to SWIFT.

94

© Wall Street Systems IPH AB - Confidential

Setting up the CMM environment

The values of the fields Request Type Name, File Information, Sender DN, Receiver DN,
Compression Algorithm, etc. are all bank dependent.

Sender and Receiver DN
ESIAdapter uses the two BIC codes, sent in the requestor_d_n and the responder_d_n from CMM
to map to the BIC codes defined in the ESICRM. These BIC codes are taken from the Client and the
Bank SWIFT Code fields.
The combination of area and syntax_and_format are combined to match a Request Type defined in
ESICRM. These are defined in the:

•

Request Type Name
Same process as above, but the Request Type Name is selected for the outbound message to
SWIFT.

•

FileInfo

•

Same process as above, but the Request Type Name is selected for the outbound message to
SWIFT.

The traffic between CMM and ESIAdapter can be seen using the Communication log group in CMM.
Here is a sample Request from CMM to ESIAdapter:
1224516070615… Communication … CaSWIFTNetAdaptor Verbose
FileAct message is generated: [FileactRequestType]
module_name:CM
unique_id:41
header:[HeaderType]
action:PUT
requestor_d_n:[DNType]
bic:TPABSUB1
extension:
common_name:null
responder_d_n:[DNType]
bic:SOCGFRPA
extension:ppe,cn=0001
common_name:null
request_type:[RequestTypeType]
area:pain
syntax_and_format:xxx.cfonb160.pay
description:
ack_indicator:true
request_crypto:true
nr_indicator:true
logical_name:afb160
compression:None
item_count:1
body:[BodyType]
content:
0302
000000

22108TEMPLATE …

The second aspect is the Logical Filename. This is transferred to SWIFT and used internally by the
bank’s systems. This Logical Filename is configured in the CMM Communication Protocol.

Note: The final value is bank dependent, with some banks accepting only names without .

characters. For example: AFB120 and not pain.xxx.cfonb160.pay. It is important to
note that this value is sent directly to the bank and is not used for any internal processing
in Wallstreet Suite.

SWIFT Connectivity Guide

95

Setting up the CMM environment

Configuration in Suite
•

Configuring the CMM Swift Fileact: syntax_and_format
The aim is to have CMM send the correct area, and syntax_and_format to ESIAdapter for
mapping to the request type.
For example:
area:pain
syntax_and_format:xxx.cfonb160.pay
Only the part after xxx needs to be configured in the CMM file
\envs\\etc\wss-web\cmm\ConfigurationData\installation\interfaces\swiftadaptor\fil
eactformatmapping.xml:


•

Configuring the CMM Communication Protocol Parameters for Logical Filename
Open the SWIFTNet Adaptor communication protocol parameters, and create a new protocol:

•

–

Parameter set name: is used to configure the bank-specific interchange

–

Party: none selected

–

Protocol: FileAct

–

Requestor DN Extension: specified by the bank

–

Responder DN Extension: specified by the bank

–

Logical Filename: specified by the bank, typically a short description without any
punctuation. For example for AFB160 formats: afb160

–

Enabled: Yes.

Configuring the CMM Interchange for FileAct
Create the interchange with the bank, and select the Format, and Communication Protocol
Parameter previously defined. The following must be set up in the sender and receiver BICs
using the ESICRM FileAct page:

96

–

BIC code must match the Swift Code in the Client Editor

–

Request Type

–

Must match the 'area', and syntax_and_format from CMM

–

DN: Provided by the BANK

–

Request Type Name: Correct SWIFT request type, provided by SWIFT

–

File Information: Provided by the BANK

–

Compression: Provided by the BANK

© Wall Street Systems IPH AB - Confidential

Setting up the CMM environment

Client Editor Showing a sample BIC code for the receiver:

CMM Communication Protocol Parameters example:

SWIFT Connectivity Guide

97

Setting up the CMM environment

Sample CMM Interchange setup

98

© Wall Street Systems IPH AB - Confidential

Setting up the CMM environment

Sample ESICRM setup for FileAct:

8.4.2.2.2 Inbound FileAct format messages from ESIAdapter
Message types concerned: non-Swift Messages, for example, AFB120.
As CMM does not understand DN names, it is up to ESIAdapter to map the incoming message from
SWIFT to a BIC code. This applies for both the Sender and Receiver BIC codes.
This is approximately the reverse process of the outbound messages from CMM. The content of the
FileAct page is used to find the corresponding BIC codes, which are sent to CMM.
The inbound FileAct message from SWIFT is parsed, and the header information used to determine
both the sender and receiver BIC codes. The following headers are parsed from the FileAct message
and their corresponding values searched for in the FileAct setup in ESICRM.

•

FileAct request type maps to Request Type Name.

•

FileAct DN maps to DN, either send or receiver.

Once the correct record is found, it is used to determine the information to be sent to CMM, which
expects the following components to be populated by ESIAdapter:

•

Sender BIC (Taken from the BIC Code field in ESICRM)

•

Receiver BIC (Taken from the BIC Code field in ESICRM)

•

Area (Split from the Request Type, for the record the BANK

•

Syntax And Format (Split from the Request Type, for the record the BANK

The traffic between CMM and ESIAdapter can be seen using the Communication log group in CMM.
Example request sent From ESIAdapter to CMM:
1224760613056 … Communication … CaSWIFTNetAdaptor Verbose
Incoming Message Received From Adaptor:[FileactRequestType]
module_name:TEST
unique_id:1224760612900
header:[HeaderType]
action:PUT
requestor_d_n:[DNType]
bic:SOCGFRPA
extension:null
common_name:null

SWIFT Connectivity Guide

99

Setting up the CMM environment

responder_d_n:[DNType]
bic:TPABSUB1
extension:null
common_name:null
request_type:[RequestTypeType]
area:camt
syntax_and_format:xxx.cfonb120.stm
description:null
ack_indicator:false
request_crypto:true
nr_indicator:true
logical_name:CM-1224760612900
compression:None
item_count:1
body:[BodyType]
content:0130004

00898EUR2 00010290739 …

8.4.2.3 Interchange setup

100

© Wall Street Systems IPH AB - Confidential

Setting up the CMM environment

SWIFT Connectivity Guide

101

Setting up the CMM environment

Example:
On the CMM-hosted server, the following setup has been done in the directory
/WSS/wss7211a_rea5/envs/rea5/etc/wss-web/cmm/ConfigurationData/installation/appserve
r/spring/interfaces:





jms.broker.host=10.35.0.130

jms.broker.port=20560


jms.broker.url=tcp://${jms.broker.host}:${jms.broker.port}?trace=true


jms.send.queue=rea5.esiadapter.in


jms.receive.queue=rea5.esiadapter.cm





102

© Wall Street Systems IPH AB - Confidential

Starting WSS processes

8.5 Starting WSS processes
To run TRMSwift, start the following server processes:
1. TRMSwift core
2. TRMSwift adapters

Note: comKIT, ActiveMQ and the associated services must be running before you start TRMSwift
adapters.

On an MSSQL installation, you can start the TRMSwift services using the Windows trusted
connection, with the following environment variable:
FK_TRUSTED_CONNECTION=1
And the following java properties (to modify in rc.trmswift or trmswift.bat)
-Dtrmswift.database.type=mssql_with_trusted_connection

8.6 Renaming TRMSwift tables
If your TRMSwift tables are not prefixed by IKIT (normal table) or IKAR (archive table), run this
command:
ant rename -Ddbms_type=[sybase|mssql|oracle] -Dold.prefix=
-Dold.archive.prefix=
where  and  are the prefixes used in your previous installation.
Example: ant rename -Ddbms_type=oracle -Dold.prefix=SH -Dold.archive.prefix=SHS
The following files will be created in the upgrade directory which you should run to rename the
tables:
rename_archivetables.sql
rename_tables.sql

8.7 Windows services
You can manage Windows services in one of the following ways:

8.7.1 Using Process Monitor
To use Process Monitor, see the TRM System Administration Guide.

8.7.2 Using the Wrapper tool
You can use TRMSwift processes as Windows processes, using the Wrapper tool. The files are
available on %FK_HOME%\etc\trmswift\windows_service.
Proceed as follows:
1. Make sure that the naming service is running
2. Make sure that TRMSwift environment variables are correctly set (they are defined in
config.bat). You can modify core.service.properties and feeder.service.properties to

give your Windows service a relevant name.

SWIFT Connectivity Guide

103

Windows services

3. Launch the services like a console ( to check that they are working):
Wrapper -c core.service.properties
Wrapper -c feeder.service.properties
To install services:
Wrapper -i core.service.properties
Wrapper -i feeder.service.properties
To remove services:
Wrapper -r core.service.properties
Wrapper -r feeder.service.properties
To activate services: Control Panel -> Administration Tool -> Component Services ->Services
Start | Stop
You can use the dependencies properties of the wrapper. For details, see the description on
wrapper.sourceforge.net.

104

© Wall Street Systems IPH AB - Confidential

Chapter 9

TRMSwift environment setup

This chapter describes the basic default setup. This setup enables you to start using TRMSwift
without any changes to the Workflow or Messages. The detailed configuration of TRMSwift is
described in later chapters.

9.1 Accessing the database
TRMSwift uses the TRM database to maintain consistency and for user verification. The TRMSwift
tables are prefixed by IKIT and IKAR.
There are two methods of accessing the TRM data:

•

Via comKIT. All data that is used to enhance a message is obtained by this method, using the
data adapter. Examples are SWIFT BIC codes, ISIN codes, and so on. When a comKIT service
does not provide all the data, and the data service cannot be used in conjunction with custom
search/stored procedures, an SQL Stored Procedure adapter can be used to access the database
directly via JDBC. comKIT hides permissioning from TRMSwift, and verifies permissioning (user
and mode) when it executes any action.

•

Using the Stored Procedure adapter for inserting State of Account entries into TRM. This method
is generally avoided because it makes upgrading more difficult. The general concept remains the
same even if comKIT changes or adds additional services.

comKIT is also used for updating TRM. After obtaining data, such as a transaction, TRM needs to be
updated with the fact that TRMSwift has received the data and, later, that messages were sent
correctly. This update is done using comKIT. In certain cases comKIT is used for creating
transactions directly in TRM, for example receiving an MT515 message.

9.2 TRMSwift XML tag structure
You can edit most of the TRMSwift XML configuration files. These files have a common content
structure, although the content will differ from file to file.
All XML configuration files within TRMSwift contain a root element of  or .
The database root element must not be modified as it defines the database schema.

Note: Sybase does not work correctly with JDBC unless you run an SQL script which is provided

by Sybase. If this script has not been installed, the XML data is truncated when written to
the database. You should also ensure that you are using jconnect5.5.jar or a later version
of JConnect.

9.2.1 Editing XML files
The TRMSwift configuration is usually contained in the files located in the dbms/xml directories. You
can also define configuration in the CSD
(Custom Specific Development) package. CSD settings are located in the package/CSD/xml

SWIFT Connectivity Guide

105

TRMSwift XML tag structure

directories. The  settings in the CSD package take precedence over settings in files
located in the dbms/xml directories, as the CSD package is loaded last.
The configuration described in this guide assumes the general TRMSwift configuration. The following
sections outline the different XML elements.

9.2.2 
The  element identifies the content of a file. In all cases it is used as the root element
of the XML and exists only for information purposes (not for configuration). There should be only
one such tag within a file. The content of the  element is determined by the type of
configuration.
This element contains two attributes: file and name. The file attribute contains the name of the file
in which the  element exists. The name attribute contains a description of the file:

The  element can contain any of the following elements: , ,
,  and .

9.2.2.1 
The  element is used to define a particular action. An  element always contains a
 element.
The content of the  element is a single  element which in turn wraps the XSLT
stylesheet containing the action. Anything within the  element is stored in the database as
part of the XSLT stylesheet.
The  element takes three attributes as described in the following table:
Attribute

Description

name

The unique name of the action. When a rule evaluates to true, the unique name identifies
the action to be performed. This attribute is mandatory.

template_list

Indicates if the action is a simple action or a multiple part action (template list). This
attribute is optional:

cacheable_list

fixed_result

•

yes: multiple part action

•

no (default): simple action.

Multiple part actions usually contain an action that is run to determine the template list. If
the template list is cacheable, this evaluating action is only run once. This attribute is
optional:
•

yes: cacheable

•

no (default): not cacheable.

Indicates that the action is not an XSLT script, but rather the resulting XML that is
produced if an XSLT script is run. If a particular XSLT script always produces the same
result, irrespective of the input XML, you can use a fixed result. The fixed result must be
enclosed in the data element and it must be valid XML. Possible values are:
•

yes: fixed result

•

no (default): not a fixed result.

The following is an example of an action:

D
$ata Setup and Action
1: 
4:

8:

9:

12:

13:
.
14:
.
15:

16:

17:

18:

19:
.
20:
.
21:
The example above indicates the  element with the two attributes as described in
section 9.2.2  on page 106.
It also contains an  element with its attributes. In this example, the action is a simple
action that is performed directly. Simple actions are cached irrespective of the cacheable_list
value.
The  element of the  element (line 8 to 17) wraps the XSLT stylesheet of the action.
Lines 19 and 20 are left open to indicate that further action, rules, rulesets or setup elements could
be defined.
The version of XSLT (on line 10) and the name space (xsl on line 11) are defined. This is standard
XSLT. See http://www.w3c.org for further details on the XSLT specification.
Whenever an action is described elsewhere in the file, it is placed within an  element in
one of the configurable XML files.

9.2.2.2 
A  element can be defined within a  element (similar to the  element).
In the previous example lines 19 and 20 were left open to indicate where these elements can be
placed.
See 12.4.2 XPath rules on page 135 for further details on defining a  element.

9.2.2.3 
A  element can be defined within a  element (similar to the  and
 elements). In the previous example lines 19 and 20 were left open to indicate where these
elements can be placed.
See 12.4.2 XPath rules on page 135 for further details on defining a  element.

9.2.2.4 
A  element is used for any configuration required by a component. This excludes
the actions, rules (or rule sets) and permissions. The  element has various
attributes to define what it is used for as well as a single  element to wrap the XML for the
configuration.

SWIFT Connectivity Guide

107

Setting environment variables

Below is a list of the attributes available for the  element. All the attributes are
mandatory:
Attribute

Description

name

This is the name of the configuration.

type

This is the type of configuration.

component_name

Typically, this is the unique name of the component to which the configuration
belongs.

The name, type and component_name attributes uniquely identify a particular configuration.

$9.2.2.4.1 setupelement
1: 
8:

9:

10:

11:
.
12:
.
13:

14:

15:

16: 
Lines 2 and 3 indicate that this is where other actions, rules, rule sets or setupelements can be
placed. The  element contains all three attributes. It also contains a single 
element that defines the XML configuration.
Whenever a component’s configuration is described elsewhere in the file, it is placed within a
 element in one of the configurable XML files.

9.3 Setting environment variables
Environment variables enable TRMSwift to:

•

Process data within a given environment.

•

Communicate with the database.

•

Communicate with TRM.

•

Identify which user id to use when starting up the system.

The TRMSwift environment variables are defined in the following files:

•

108

Windows: share/environments/config.bat

© Wall Street Systems IPH AB - Confidential

Setting package properties

•

Unix: share/environments/trmswift_config.pl
Property Name

Description

TRMSWIFT_USER

The name of the user that is used to connect to the database when running all
components.

TRMSWIFT_PASSWORD

The password that corresponds to the user name which is defined in
trmswift.user.name.

TRMSWIFT_SERVICE

The "service" of the TRM naming service where comKIT is registered. The
service must correspond to the FK_COMKIT_SETUP variable as defined in the
TRM environment.

TRMSWIFT_COMPONENT

he trmswift.feeder.component property is used to determine the parts of
the Adapter framework to be activated. It allows various read and write
adapter groups to be enabled. The values are colon-separated and can be any
of those listed in the component_type attribute of an adapter's XML
configuration file.
Example 1. This example activates comKIT and SWIFT file adapters for TRM,
all filters, all system adapters (like email, etc) and OTHER.

trmswift.feeder.component=OTHER:FILTER:COMKIT:SWIFTFILE:SYSTE
M
It is also possible to enable only only certain read or write sections of the
adapter. The list should contain the name of the read or write section (as
specified by  in the XML configuration) along with whether it
is the read or write section. Only these sections listed will be activated. If no
sections are listed as in this example, all read and write sections of the listed
adapter groups will be activated. If any the read or write sections do not
exist, they are ignored.
Example 2: As Example 1, except that only the FX-SpotConfirmation read
section will be activated for the COMKIT adapter group. The "R|" indicates it
is a read section. This is the default, so it can be left out. No write sections
will be activated for the COMKIT adapter group.

trmswift.feeder.component=OTHER:FILTER:COMKIT(R|FX-SpotConfir
mation):SWIFTFILE:SYSTEM
or

trmswift.feeder.component=OTHER:FILTER:COMKIT(FX-SpotConfirma
tion):SWIFTFILE:SYSTEM
Example 3: As Example 2, except that the FX-SwapConfirmation read section
will also be activated. No write sections will be activated for the COMKIT
adapter group. Note that different sections must be separated by a pipe (|)
sign.

9.4 Setting package properties
Depending on the package you want to use, you should define and modify certain variables. These
are defined in a properties file located in the package/ directory.

SWIFT Connectivity Guide

109

Setting package properties

9.4.1 Feeder
In the package/GENERAL/general.properties file:
Property Name

Description

filefeeder.output.path

This is the directory where output message files are placed. This is generally
the parent directory. The adapter configuration determines the full path.
Use the question mark symbol (?) to define path separators and not forward
(/) or backward (\) slashes. You do not need to place a separator at the end
of the property.

comkit.result.mode

This property permits to specify the result mode used by comkit. (by default
the value is AS-LOCAL)

comkit.command.parameters

Parameters that are used when fetching transactions via comKIT. This
applies to all confirmation adapters. Generally it also applies to any
transaction adapters. However, you can apply these parameters to specific
transaction adapters only.
The XML definition is as follows:

name_of_field
value_of_field

The name of the field is derived from the Transaction field in the comKIT
interface. You can view the possible values in the comKIT metadata.
For example, to find transactions within a portfolio (or sub-portfolio) called
DEMO, you would define the following:

portfolio_id
DEMO


trmswift.feeder.component=OTHER:FILTER:COMKIT(R|FX-SpotConfi
rmation|R|FX-SwapConfirmation):SWIFTFILE:SYSTEM
or

trmswift.feeder.component=OTHER:FILTER:COMKIT(FX-SpotConfirm
ation|FX-SwapConfirmation):SWIFTFILE:SYSTEM
Example 4: As Example 3, except that the (fictitious) write section named
FX-Writer will also be activated. The "W|" indicates the last section is a
write section. As "R|" is the default, "W|" must be specified.

trmswift.feeder.component=OTHER:FILTER:COMKIT(R|FX-SpotConfi
rmation|R|FX-SwapConfirmation|W|FX-Writer):SWIFTFILE:SYSTEM
or

trmswift.feeder.component=OTHER:FILTER:COMKIT(FX-SpotConfirm
ation|FX-SwapConfirmation|W|FX-Writer):SWIFTFILE:SYSTEM
Example 5: As Example 4, except that neither of the two read sections will
be activated.

trmswift.feeder.component=OTHER:FILTER:COMKIT(W|FX-Writer):S
WIFTFILE:SYSTEM

110

© Wall Street Systems IPH AB - Confidential

Setting SWIFT properties

Property Name

Description
Below is a list of valid (standard) values. When creating a CSD, you can
extend this list as desired.
•

CASMF: connects to SWIFTAlliance Access for the CASmf API

•

COMKIT: used for Payments, Cancel Payments, BA- FXMM-Confirmations, Cancel Confirmations, Cashflow Fixing Confirmations,
Fax Confirmations, Statement of Accounts (MT950), and creating TRM
transactions for TRM

•

COMKIT-CALL: used for the Call adapter for TRM 5.1

•

FIX: used for sending FIX messages in conjunction with OMM

•

OMM: used to connect to OMM

•

RTGS: used for the Bank of Finland’s system

•

SWIFTFILE: used for creating SWIFT files for TRM 5.0

•

SWIFTLOAN: used for incoming loans

•

SYSTEM: used for email, printers, files and by packages. This value
should always be included

•

TRAM: used to connect TRM 5.0 to CityNet Matching

•

FILTER: indicates which filters are used, typically used for SWIFT, FAX,
CMM or TRAM.

•

OTHER: defines various connectors, filters, and factories. See
package/GENERAL//feeder/feeder_conf.xml for more details.

9.4.2 Printer
In the package/GENERAL/general.properties file:
Property Name

Description

feeder.printer.name

•

UNIX: the printer IP address and type.
For example: 127.0.0.1:raw

•

Windows: path to the device.
For example: \\machine\name\device

9.4.3 Email
In the package/GENERAL/general.properties file:
Property Name

Description

feeder.smtpserver.server

The IP address of the mail server.

feeder.email.to

The email address of the recipient.

feeder.email.from

The email address of the sender.

feeder.email.subj

The subject of the email.

9.5 Setting SWIFT properties
These are in the file etc/trmswift/package/SWIFT/swift_properties:

SWIFT Connectivity Guide

111

Setting SWIFT properties

9.5.1 CASmf
Property Name

Description

feeder.casmf.mapid

The mapid setup in the DMAPID.DAT file in CASmf.

feeder.casmf.acknack

A boolean value:
•

true: the TRMSwift adapter waits for an acknowledgement
from CASmf before determining the success or failure of a
message

•

false (default): the TRMSwift adapter does not wait.

9.5.2 SWIFT header
Property Name

Description

swift.decoder.field_1

The field that is created when parsing the header 1 in a SWIFT
message. The default value is sender. This value must be set to
receiver when using CASmf.

swift.decoder.field_2

The field that is created when parsing the header 2 in a SWIFT
message. The default value is receiver. This value must be set to
sender when using CASmf.

swift.decoder.field_2_extra

Captures additional characters when using CASmf. It should be set
to .{10} when using CASmf.

swift.fk.version

The version of TRM joiners to use:

swift.header.terminal

•

for TRM 5.0 set to blank

•

for TRM 5.1 set to 51

•

for TRM 6.0 set to 60

The SWIFT Terminal code to use when sending SWIFT messages.
Set this value to the code of your logical SWIFT terminal. Empty
values result in a BIC code which is too short.

9.5.3 MT515
Property Name

Description

MT515.incoming.cp_client_id

The counterparty client id for T-BILLS and REPOS. The default
value is FRNYNYC.

MT515.incoming.market_id

The market id for T-BILLS and REPOS. The default value is MM.

MT515.incoming.repo.instrumentId

The instrument id for REPOS. The default value is REPO-AUTO.

portfolio.property.t-bill

The portfolio property for T-BILLS which specifies the
corresponding account number. The default value is
MT515-ACCOUNT-BILL.

portfolio.property.repo

The portfolio property for REPOS which specifies the
corresponding account number. The default value is
MT515-ACCOUNT-REPO.

112

© Wall Street Systems IPH AB - Confidential

Setting TRMSwift properties

9.6 Setting TRMSwift properties
Some properties are hidden and can be used to modify the behavior of TRMSwift. These properties
are defined in trmswift.properties, supplied in the TRMSwift library (JAR).
They can be overwritten in trmswift.bat and rc.trmswift.shf adding the java parameter
Dtrmswift.properties=value. They can also be defined in the TRMSWFT_PROPERTIES environment
variable.

9.6.1 Ports
Among the internal properties, the four listed in the table below allow TRMSwift to control the TCP
ports that are allocated to CORBA communications:
Property Name

Description

trmswift.orb.port

Remote port opened by the ORB naming service. Syntax:

trmswift.orb.port = 
trmswift.client.port

Outgoing communication port range. Syntax:

trmswift.client.port = :
Example TRMSwift Message Monitor using local ports from 5550 to 5559.
Bi-directional GIOP is implicitely enabled:

set TRMSWIFT_PROPERTIES=-Dtrmswift.client.port=5550:5559
trmswift.bat mmo
trmswift.server.port

Incoming communication port range. Syntax:

trmswift.server.port = :
Example TRMSwift core allowing client connections on ports from 6550 to 6559.
Bi-directional GIOP is implicitely enabled:

set TRMSWIFT_PROPERTIES=-Dtrmswift.server.port=6550:6559
trmswift.bat core
trmswift.orb.bidir.giop

Activation of bi-directional GIOP (General Inter-ORB Protocol).
This forces a request (sent by a client) and its response (returned by a server) to use
the same connection. It limits the number of connections and ports opened.
This property is internally enabled whenever the trmswift.client.port or

trmswift.server.port is defined. Syntax:

trmswift.orb.bidir.giop = true|false

9.6.2 Static data refresh and TRMSwift-comKIT communication
Property name

Description

trmswift.comkit.heart.beat.period

The period of heartbeats (in seconds) sent to comKIT. Its default
value is 600 seconds (10 minutes).

9.7 Setting up TRM
You need to configure TRM to enable TRMSwift to obtain data from TRM and to update TRM with the
results (successful or otherwise) of messages.
All communication to TRM is done via comKIT. All data that is used to enhance a message is
obtained by this method, using the data adapter. Examples are SWIFT BIC codes, ISIN codes, and

SWIFT Connectivity Guide

113

Setting up TRM

so on. When a comKIT service does not provide all the data, and the data service cannot be used in
conjunction with custom search/stored procedures, an SQL Stored Procedure adapter can be used to
access the database directly via JDBC.
comKIT is also used for updating TRM. After obtaining data, such as a transaction, TRM needs to be
updated with the fact that TRMSwift has received the data and, later, that the message(s) was sent
correctly. This update is done using comKIT. In certain cases comKIT is used for creating
transactions directly in TRM, for example receiving an MT515 message.

9.7.1 Configuring the transaction flow
To send various confirmation messages, you must modify the transaction flow of TRM. Below is an
example of a transaction state flow that has been modified for TRMSwift (the dotted parts indicate
the configuration which has been added for TRMSwift):

5
2

Transaction
state flow

Open

Verify

Final
1

4
SH-CONF

Transaction
modes

SH-WAIT

6

7

SH-GET

SH-HOLD

8

9

Integration KIT
adapter

Integration KIT
core

3

Adapter

10

11

Inbound
Message
Handler

Business
Event
Notifyer

TRMSwift uses two modes to process a business event. The first mode indicates which transaction is
picked up for processing (SH-GET in the example). The second mode is used to find the transaction
again so that it can be updated with the status of the sending of messages (SH-HOLD in the
example).

9.7.1.1 Getting the data
Before the transaction becomes available within the TRMSwift mode, it must be accepted by a user
of TRM. The underlying transaction flow then accepts the transaction to the next state (1).
When TRMSwift (one of its adapters) determines that a transaction exists (using the mode SH-GET),
the adapter uses comKIT to copy data from the transaction and creates a block of XML (8). This
block of XML is passed to TRMSwift (via the Inbound Message Handler) and safe stored within the
TRMSwift database (10).
TRMSwift informs the adapter that the business event has been created and safe stored successfully
(also 10). The adapter then uses comKIT to accept the transaction (7, 5 and 3). The underlying
configuration of what the mode does, does not matter to TRMSwift. The only condition is that the
transaction is no longer visible within the given mode (SH-GET in this case).
If the business event cannot be safe stored within TRMSwift, the Inbound Message Handler notifies
the adapter that it should not accept the transaction (using the mode), but rather reject it (7, 5 and

114

© Wall Street Systems IPH AB - Confidential

Setting up TRM

2). Depending on the configuration of the mode and transaction state flow, the transaction reverts
to a state earlier in the transaction flow.
In the example above, the SH-GET mode picks up transactions that are in the SH-CONF state (6).
Once they are picked up, they are moved to the SH-WAIT state (3). If they are not picked up
correctly, they are rejected to the Verify state (2).
The adapter uses the mode together with any other additional criteria specified by the adapter
configuration to determine which transactions to pick up. For example, several adapters may use
the same mode to pick up transactions. However, one adapter may only be interested in one type of
transaction. You would therefore specify additional criteria to identify the required transactions.

9.7.1.2 Success or failure
When TRMSwift has finished processing the business event (and creating the associated messages),
the Business Event Notifyer indicates to the adapter that the business event was successful (11).
The adapter in turn uses comKIT to accept the transaction using the mode SH-HOLD (9).
The Business Event Notifyer uses the mode and the transaction number to identify the transaction
that is accepted or rejected.
In the example, if the status is a success (message(s) are sent correctly), the transaction is
accepted to the Final state (4). However, if the status is a failure, the transaction is rejected to the
Verify state (5).

9.7.1.3 Modes
Modes enable transactions to be selected and identified. It does not matter whether a mode is a
state or a status, so long as it identifies a transaction.
In the example, the modes use states to identify the transactions that are selected as well as the
transactions that are marked as successful or as failed. The modes could have been configured as
statuses.

9.7.1.4 Cancelling transactions
When a transaction is cancelled by TRM, it undergoes a similar process to when a transaction is
accepted within the transaction state flow. A transaction can be accepted (or rejected) to a state
with a corresponding mode that identifies the transaction for processing within TRMSwift.
However, if a transaction is cancelled (using the cancel functionality) and is not rejected (using the
accept/reject functionality), the transaction is not made available to such a mode and is therefore
not processed by TRMSwift.

9.7.1.5 Creating transaction rules
There are two conditions under which you must create rules within TRM:

•

Transaction flow
You must determine the flow of a transaction within the transaction state flow. For example, only
FX Spot/Forward transactions are sent to TRMSwift. If a user accepts a transaction that is in
state Verify (as in the example on page 114), the rules determine if the transaction is sent to
SH-CONF or to Final. You could also configure that only those transactions that require a
confirmation message are sent to TRMSwift.

•

Pickup criteria
You must determine the criteria that an adapter uses to identify the transactions to pick up (via
the mode). For example, you can specify rules to which a transaction must adhere. If you define
a rule to identify FX Spot/Forward transactions and the adapter is configured to only pick up
transactions that adhere to this rule, the adapter only picks up FX Spot/Forward transactions.

9.7.2 Configuring the payment flow
The payment flow works in the same way as the transaction state flow. You use adapters, modes,
states and flags in the payment flow in the same way as you use them in the transaction flow.

SWIFT Connectivity Guide

115

Setting up TRM

However, the criteria that you define is different, as different data is provided for a payment. See
the comKIT description in the TRM System Administration Guide for a description of the data that is
provided for payments.

9.7.2.1 Creating settlement transfer methods and rules
When generating payments (using Settlement Manager or Activity Manager), the payment’s transfer
type (method) is determined according to the Settlement Transfer Methods and Rules. These rules
are evaluated in order of priority to determine the transfer method for a payment. TRMSwift uses
the transfer type of the payment to determine which type of message to create.
The transfer type is prefixed with SWIFT- to identify that it is picked up by TRMSwift. This prefix is
required by adapters that pick up payments. If the payment is an MT202, the transfer type is
SWIFT-MT202. The flattener of the adapter removes the SWIFT- prefix so that the business event
has the correct method. The Business Event Splitter uses the updated transfer type. In this way, the
Business Event Splitter can overrule decisions made in the Settlement Manager (within TRM).

116

© Wall Street Systems IPH AB - Confidential

Chapter 10 TRMSwift security and permissions
setup

TRMSwift offers a solid protection model with tools for authentication, auditing, and access control.
This chapter describes the security features of TRMSwift.

10.1 Guaranteeing security across the network
TRMSwift communicates with remote objects, applications and network nodes through CORBA.When
interconnecting systems involve proprietary applications or closed systems, such environments do
not offer a means to automatically upload messages generated by an external application. These
environments may also impose security policies such as isolation of sensitive systems.
In such cases, TRMSwift uses temporary files to store messages. These files are stored for an
indefinite amount of time until they are manually loaded or sent by ftp to the proprietary systems by
an authorized Administrator.

10.1.1 Implementing encryption over the network
TRMSwift does not provide encryption of data sent to local or remote applications. This task is
delegated to the specific adapters that reside above TRMSwift. For example, SWIFTAlliance CASmf
provides an encryption and authentication means between the CASmf based adapter and the
SWIFTAlliance CBT.
If encryption is required to deliver secure communication with secure systems, WSS recommends
implementing hardware encryption between network nodes where the communicating applications
run.

10.1.2 Identifying network objects
Any application or system that interconnects and communicates with the TRMSwift Core module
must be defined in the TRMSwift Core environment.
The following exceptions apply to processing and accepting connection requests:

•

Incoming information is only accepted from adapters with a valid identification registered in the
TRMSwift core database.

•

Outgoing information is only sent to adapters with a valid identification registered in the
TRMSwift core database.

•

Unregistered adapters may connect to TRMSwift but the TRMSwift core does not truly
communicate with them until their identification has been provided within the TRMSwift context.

The System and Message Monitors are implemented as dedicated servers embedded in the
TRMSwift core. Embedded servers refuse connection requests issued by modules other than the
System or the Message Monitor.

Note: All modules that are connected to the TRMSwift core can be monitored and manipulated by
the System Monitor even if they are not defined in the core environment.

SWIFT Connectivity Guide

117

Audit Manager

10.1.3 File system security
You should place TRMSwift scripts on a secure file system to avoid the following:

•

Impersonation
Replacement of an image or an executable script by another file that acts in the same way (Java
is interpreted to a certain degree and can be decompiled)

•

Message tampering
Modification of a message stored in an unprotected temporary file by an unauthorized user

•

Uncontrolled change of setup
Unauthorized change of a parameter in a unprotected script and uploading of the setup in the
central database by an authorized user.

10.2 Audit Manager
Audit Manager is a process that interacts between each of the TRMSwift components and the
database.
Auditing functions are built in to the modules in the workflow and are triggered as soon as a
business event or message enters or leaves a workflow state or predefined module. There are three
auditing functions:

•

Add to error log

•

This enables you to track any processing errors for the message.

•

Add to workflow log

•

This enables you to track the workflow of the message; that is, the components that have
processed the message.

•

Add to system log

•

This enables you to track system level events. Logged system events are the activation,
configuration, suspension or shutdown of a component, the failure of those actions due to
missing permissions, and the registration of a component with the core.

10.3 TRMSwift data workflow
The process of handling and controlling messages from initial entry as a business event to final
delivery is referred to as the workflow. The workflow requires a number of predefined states to
manipulate data and translate it into a format that can easily be dispatched to a third party. The
Workflow Controller manages these states and is responsible for the movement of messages from
one state to another.
TRMSwift enables you to define the workflow for different payments, confirmations and custody
transfers. TRMSwift also enables you to define states to include in the workflow to suit your own
message management and verification business requirements. States are defined at setup time in
the database.
Modes define the action to apply to a message after it enters a particular state in the workflow. A
mode can be attached to one or more states. Modes determines the actions that are available to
you; these actions are configured at setup time. You can restrict user access to certain modes only.

10.3.1 Verifying messages
Within TRMSwift, you use Message Monitor to review messages associated with a particular mode.
To enforce TRMSwift's four-eyes principle, you can configure modes for message verification with
authorization capabilities.

118

© Wall Street Systems IPH AB - Confidential

Database security

Four-eyed principle auditors must be granted specific rights at application level (in the Permission
Manager) to access messages in the verification states.

10.4 Database security
The database system centrally enforces integrity and security. Data integrity and security cannot be
circumvented by other applications.
Some of the main features implemented to enforce security at the database level are as follows:

•

TRMSwift core objects, tables, user definitions and passwords are safe stored in the database at
installation time. Any modification to this data is either performed by an TRMSwift module with
the required authorization, or requires the help of a Database Administrator (DBA). The DBA
must import system parameters and definitions used by the TRMSwift modules. The TRMSwift
Administrator is responsible for starting a reconfigure operation enabling the modules requiring
such parameters to extract them from the database.

•

Data encryption is handled by the underlying database system.

•

Data access control is partially handled at the database level.

10.4.1 Identification and authentication
Every user or entity (including TRMSwift daemons and background processes) is provided with a
password-protected unique ID to access or manipulate TRMSwift data and its graphical user
interface. Identification and authentication is mandatory to access TRMSwift data.

10.4.1.1 Logging into TRMSwift
A default user is defined in TRM:trmswift.
You can enable re-use of TRM user IDs and passwords by setting up the TRMSwift database to share
the TRM database. You do not need to replicate the TRM database or the users’ table. TRM and
TRMSwift are fully compatible when addressing the same database space.
Upon successful login to TRMSwift, the user ID is checked against the database to verify the user's
access rights. Identification ensures that activities performed by TRMSwift users can be audited.

10.4.1.2 Entering passwords
TRMSwift modules recognize passwords when they are presented at the command line level.
Otherwise a login window is presented to the user to enter the appropriate user IDs and passwords.
Presenting passwords at the command line ensures that TRMSwift can be started according to a
defined schedule and without manual intervention. However, entering user IDs and passwords by
using the login window is recommended as it prevents password eavesdropping, which can occur
when listing processes at the command line level on specific operating systems (UNIX based
systems).

10.4.2 Division of roles in TRMSwift
The use of roles provides accountability for users performing system administration and
business-related tasks. The division of roles is implemented at both the database level and the
software level.

SWIFT Connectivity Guide

119

Database security

10.4.2.1 Privileged user "trmswift"
The privileged database user is required to run the TRMSwift core. This user has to be granted
SELECT, INSERT, UPDATE and DELETE rights for all tables and records in the TRMSwift database.
The default installation creates the user trmswift with all the above privileges.

Note: You may also use the user fk on Sybase and MSSQL, or the user dbo on Oracle to run the
TRMSwift core. This user has all the privileges described above.

10.4.2.2 Defining non-privileged users
TRMSwift users accessing TRMSwift data through one of the TRMSwift GUIs or some of the adapters
also require a password-protected database user. These users do not however require RDBMS
privileges because their rights are defined in Permission Editor (available from Security Center).
TRMSwift-related permission objects can be found in the permission hierarchy under SWIFT /
TRMSwift.

Note: A privileged user ID is required to run an adapter if the adapter needs to fetch data from a

database. All the adapters residing between TRM and the TRMSwift core have, for security
reasons, their own configuration scheme stored in the database and run under the same ID
as the core.

120

© Wall Street Systems IPH AB - Confidential

Chapter 11

TRMSwift routine maintenance

11.1 Overview
TRMSwift should be stopped each day so that normal maintenance tasks can be performed. These
maintenance tasks should adhere to the customer’s IT standards, and should include the following
tasks at least:

•

Taking backups of the database

•

Performing archiving of data

•

Rebuilding of database indexes/statistics

These maintenance tasks should normally be carried out at the same time that TRM maintenance
(similar to above) is performed.
TRMSwift should be stopped before comKIT is stopped, and started after comKIT has been started.
This avoids unnecessary warning messages of not being able to contact comKIT.

Note: TRMSwift process log files are generated in %FK_HOME%\var\log\trmswift. They are
automatically backed up in %FK_HOME%\var\log\trmswift\backup.

11.2 Scheduling actions
The Scheduler component triggers actions on workflow elements at specified times. For example,
the InboundMessageHandler may have an action which polls specific adapters for new business
events or messages.
Scheduler configuration is defined in setup.xml.
You use a setupelement with the following attributes:
Attribute

Description/Value

name

SETUP

type

GENERAL

component_name

component_name

The component_name (shown here and in the following example) corresponds to the unique name
of the Scheduler as defined in the property trmswift.sc.name in ikit.properties. The default
value is Scheduler.
Scheduler



15,45
8-18
*

SWIFT Connectivity Guide

121

Scheduling actions

6
1-5
America/New_York






00
10
*
*
1-5






You can schedule several jobs, each one containing a schedule date and an action. The action is
wrapped in an  element and contains two attributes component_name and name. The
component_name specifies on which component this action is performed and the name specifies
the name of the action for that component.
The definition of the schedule date is wrapped in a  element and contains the
sub-elements that are described below (similar to the cron command in Unix). With the exception of
the time zone, you should use a comma between multiple values, a hyphen to indicate a range, and
an asterisk to indicate all possible values. Leaving the element empty indicates all possible values.
The job is executed every year at the scheduled date.
Element

Valid range



0-59

Example
*
Occurs every minute



0-23

8-18, 23
Occurs every hour from 8.00 to 18.00 and once at
23.00



1-31

1
Occurs on the first of the month



1-12

4
Occurs in April





0-6

1-5

where 0 = Sunday

Occurs every day from Monday to Friday

Valid time zones are listed in
Appendix B Time zones on page
275.

America/New_York 
Uses the New York time zone

If no time zone is specified, the
default time zone is used.

Note: You cannot configure the Scheduler to check if a day is a bank holiday.
You can re-configure the Scheduler while it is running, using the Re-configure option in the System
Monitor.

122

© Wall Street Systems IPH AB - Confidential

Displaying the current TRMSwift configuration

11.3 Displaying the current TRMSwift configuration
You can display the IKITSetupElement, and/or IKITXPathRule, and/or IKITAction tables in an
easy-to-read log file by using the trmswift dump command.
In a TRM-evaluated environment, open a shell (or Windows Command Prompt) and enter this
command at the command line:
Unix:
rc.trmswift dump IKITSetupElement, IKITXPathRule, IKITAction
Windows:
trmswift dump IKITSetupElement, IKITXPathRule, IKITAction

Note: The upload_* columns in these tables enable you to identify the machine and file that each
row was loaded from.

SWIFT Connectivity Guide

123

Displaying the current TRMSwift configuration

124

© Wall Street Systems IPH AB - Confidential

Chapter 12

TRMSwift message configuration

This chapter explains how to create new messages and configure existing ones.

12.1 Creating a new message
The following steps outline how to create a new message:

•

Obtain data: ensure that the correct data is being obtained in the business event. You can
either create a new adapter or modify an existing adapter.

•

Understand data: ensure that TRMSwift understands the business event data that is received
from the adapter. You do this by changing the rules and actions of the Inbound Message Handler.

•

Decide on message(s): decide which message(s) to send for the business event. You do this
by changing the rules and actions of the Business Event Splitter.

•

Verify the message(s): you do this by configuring the workflow.

•

Format the message(s): you do this by changing the rules and actions of the Encoder.

•

Send the message(s): define the adapter(s) to which message(s) are sent and send them.
You do this by changing the rules and actions of the Outbound Message Handler.

•

Notify TRM: inform the adapter to update TRM on whether the business event was received.
You do this by configuring the Business Event Reconciliator and Business Event Notifyer.

12.1.1 Obtaining data
You obtain data from business events in the originating system (TRM) by configuring adapters. You
can modify an existing adapter or create a new one. For more information on adapters, see Chapter
14 TRMSwift adapter configuration on page 179.

12.1.1.1 Modifying an existing adapter
You can add the required fields to the business event being fetched or you can add the required
fields to existing joins. You can also add joins that pick up data from additional sources. The fields
become available within the flattener and are passed to TRMSwift.

12.1.1.2 Creating a new adapter
When you create a new adapter, it is likely that you must do some additional configuration within
TRM. For example, some adapters use data such as a rule to which a transaction must adhere. You
specify this data within the adapter as parameters. If the corresponding rules do not exist within
TRM, you must also create them in TRM.
The required data must be contained in the fields that are picked up by the adapter or in any joins
which have been created.

12.1.2 Understanding data
The Inbound Message Handler expects XML received from an adapter to be in a particular format.
The Inbound Message Handler changes the received XML, using rules and actions, so that it is easier
to work with.

SWIFT Connectivity Guide

125

Creating a new message

For more information on the Inbound Message Handler, see 13.2.3.1 Inbound Message Handler on
page 153.

12.1.3 Deciding on message(s)
The Business Event Splitter determines the message(s) that are created from a business event. You
configure the Business Event Splitter by:

•

Defining rules in the Business Event Splitter
Rules are Xpath expressions that are pattern matched in the XML provided by the Inbound
Message Handler. Rules are evaluated according to priority and determine the actions that are
performed on the business event. For more information, see 12.4.2 XPath rules on page 135.

•

Using actions to copy business event data
Actions determine the type of message that is created. Data is copied from the business event to
message(s) and sequence(s). Some actions require further logic to determine the message type.
This logic is provided by XSLT actions. XSLT actions create blocks of XML. For an example, see
12.5.2.2 XSLT actions on page 139.

12.1.4 Verifying the message(s)
•

To enable users to verify messages, you need to configure the following:

•

The workflow for the business event or message

•

What the user can preview

•

Message Monitor columns.

12.1.4.1 Setting up the workflow
Depending on your requirements, you can either add new elements (states) to the workflow or
enable the business event or message to take a different route through the workflow.
To change the routing capabilities of a business event or message, you can either configure the
Message Monitor actions (see 15.5.4 Modes and actions on page 227) or the workflow deciders (see
13.2.2 Defining workflow deciders on page 152).

12.1.4.2 Previewing the messages
Encoder actions determine what the user can preview. The Message Monitor previewer takes the
output from the Encoder and displays it. For information on configuring previewers, see 15.5.2
Previewers on page 223.

12.1.4.3 Adding columns to the Message Monitor
Users verify or accept messages using Message Monitor. Messages can be verified when a user
previews a message or views column data.
For information on adding columns see 15.5.3 Columns on page 224. For information on extracting
data to be displayed in a column, see 12.3 Constructed XML on page 128.

12.1.5 Formatting the message(s)
When you create a new message, you need to define rules and actions for that message in the
Encoder. The new rules are slotted into the existing rule set with the relevant priority. The action
defines the structure and content of the message. To facilitate configuration of SWIFT messages,
you can use the SWIFT_TAGIFIER (see 12.5.5 SWIFT Tagifyer on page 144).
Each Encoder section is split over two files. The first file contains the standard format in which a
message is encoded, such as encoderMT2.xml. The second file contains the rules defining which

126

© Wall Street Systems IPH AB - Confidential

Configuring existing messages

encoder to use. The second file also contains the template list of actions to perform to generate the
message (for example encoderMT2-rules.xml).

Note: Do not edit the distribution file if you want to change the encoding of a message. You must

create an additional file containing the new action. For example, to modify MT202, do not
edit encoderMT2.xml; create a new file, such as encoderMT2-site.xml, containing an action
XMLEF_MT202 _SITE. Edit the encoderMT2-rules.xml file, by adding the XMLEF_MT202
_SITE action in the template list (generally after the XMLEF_MT202 action but before the
SWIFT_TAGIFYER action). See also 12.5.2.4 Template list hooks on page 140.

12.1.6 Sending the message(s)
When you create a new message, it can either be sent to the same list of adapters or a new adapter.
If a message is sent to a new adapter, you must change the actions of the Outbound Message
Handler. You can either change existing actions within the Outbound Message Handler or add a new
action. If you add a new action, you also need to define the rules that select the action.
For more information, see 13.2.3.4 OutboundMessageHandler on page 161.

12.1.7 Notifying TRM of success or failure
When you add a new message, success or failure may be determined in a different way. You may
need to create new conditions for the Reconciliator and Business Event Notifyer. See 13.2.3.5
Reconciliator on page 164 and 13.2.3.6 BusinessEventNotifyer on page 166, for more information.

12.2 Configuring existing messages
12.2.1 Adding a new field to a message
In the example below, when a root message element /message is found, the  element
is created and its contents are copied by applying templates. A new field, called new_field is added
to the message with the value New fields value.
Adding a new field to the message
1:
2: 
3:

4:
New fields value
5: 
6:
Instead of configuring a hard-coded value, you could use various XSLT methods to obtain a value
from other sources.

12.2.2 Changing a value
In the example below, when the amount in a sequence sequence/amount is matched, its value is
replaced by finding the value of other_amount.
Changing the amount value
1: 
2:
3: 

SWIFT Connectivity Guide

127

Constructed XML

12.2.3 Removing a value
In the example below, when sequence/account_id is matched, the value is not copied and is
therefore removed.
1: 

12.3 Constructed XML
The XML that is produced by adapters and subsequently transformed by the Inbound Message
Handler is not the same as the XML used by components. XML produced by adapters and the
Inbound Message Handler only includes business-related data. It does not include related data, such
as the history of a transaction, related messages or sequences.
Constructed XML is composed from the related business events, messages and sequences. This is
the XML that is used by components.
Constructed XML is composed differently depending on whether it is being constructed for a
business event or a message.

12.3.1 Business event
A business event has various sets of related data that are included in the constructed XML. The
related data is specified within a single  element.

12.3.1.1 Administrative data
The administrative data for the business event is created from the database table StateElement. The
data is specified as attributes within the top level  element:
Attribute

Description

id

Uniquely identifies the business event or message in TRMSwift. It is also
used to access the base XML related to the business event (see 12.3.1.3
Original data received from the adapter on page 130).

context

Determines the element on which rules or actions are performed. See
the table on page 129 for more information.

context_type

The type of the context, for example, workflow. See the table on page
129 for more information.

owner

The owner of the business event. This is the unique name of the adapter
from which the business event was received.

ownertype

The owner type of the business event. This is the content of the
 tag as produced by the Inbound Message Handler.

reference

The reference with which the business event was received.
If the adapter picks up transactions from TRM, the reference number is
the transaction number (from the transaction table).
If the adapter picks up payments from TRM, the reference number is
the transaction number (from the payment table) or 0 if it is a netted
payment. This is followed by a minus sign (-) together with the
payment id (id from the payment table).

stamp
elementtype

128

A string representation of the timestamp of the business event.
The type of state element:
•

businessevent

•

message.

© Wall Street Systems IPH AB - Confidential

Constructed XML

Attribute

Description

systemflagsi,
userflagsi,
systemflags,
userflags,
allflags and


The various system or user flags that are set at the time that the XML is
constructed:
•

systemflagsi and userflagsi: represent the integer value

•

systemflags and userflags: represent a comma separated string of
the unique name of the flags

•

allflags: represents a comma separated string of all the flags from
either set (system or user)

•

 sub-tag: each flag (system or user) is represented as a
sub-tag of  so that it can be used for XPath expressions.

state

The state of the current workflow element for the business event.

creationdate

The date the business event was created.

modificationdate

The date of the last modification.

Constructed XML for administrative data





.
.

The context and context_type attributes enable messages to be formatted according to the
adapter to which the message is being sent, for example SWIFT or Telex.
The following table describes the various contexts and context types:
Component

context_type

context

InboundMessageHandler

Workflow

Unique name of the component

BusinessEventSplitter

Workflow

Unique name of the component

KeyLoader

Workflow

Unique name of the component

BusinessEventNotifyer

Workflow

Unique name of the component

MessageMerger

Workflow

Unique name of the component

SWIFT Connectivity Guide

129

Constructed XML

Component

context_type

context

Waiter

Workflow

Unique name of the component

OutboundMessageHandler
(safe storing the delivery
element before sending it)

Workflow

Unique name of the Outbound Message
Handler

OutboundMessageHandler
(sending the delivery
element)

Feeder

Name of the delivery component

WorkflowDecider

WorkflowDecider

Unique name of the component

MessageMonitor

MessageMonitor

Unique name of the component

Previewer

Previewer

Name of previewer

PurgeManager

PurgeManager

PurgeManager

ActionDoer

Workflow

Unique name of the component

ElementExtractor

Debug

ElementExtractor

DatabaseLib

Extension

DatabaseLib

12.3.1.2 Keys and values
Keys and values enable the encoder or Message Monitor to extract values from a business event.
Constructed XML for keys and values



123-456
2243
100000.00
2002-04-28 00:00:00
USD


.
.

The  tag contains a list of keys and their associated values. Each key may contain a type
attribute to indicate the data type. Possible types are:

•

Long: integer numbers (such as ID)

•

Money: currency values (such as amount, rate or fraction)

•

Date: date/time values in the format yyyy-MM-dd hh:mm:ss.

If type is not specified, the default setting is Text.

12.3.1.3 Original data received from the adapter
The XML that was originally received from the adapter is also included. The Inbound Message
Handler wraps the original data its own  element as shown in line 9 below:
Constructed XML for original data (base data)

130

© Wall Street Systems IPH AB - Confidential

Constructed XML





CONFIRMATION
FXSpotForward
12590
2001-02-03
.
.

.
.


12.3.1.4 Relationship to other business events
The Inbound Message Handler retrieves related business events and includes these in the
constructed XML. The Inbound Message Handler does not retrieve the business events recursively,
so previous business events are not included.
Constructed XML for related business events





.
.

Related business events are defined using the  tag. In the example, business event 123
has two related business events. Business events with a different relationship, for example rollover,
would be constructed after line 18, using a  tag.

12.3.1.5 Related messages
Messages that are related to the business event via a sequence are also included in the constructed
XML.
Constructed XML for related messages




The example shows two messages that are related to the business event (see below for more
information on message data).

12.3.2 Message
A message has various sets of related data that are assigned by the Business Event Splitter when
the message is created. The related data is specified in the constructed XML within a single
 element.

12.3.2.1 Administrative data
The administrative data for the message is created from the database table StateElement.
The following table describes the various attributes and sub-tags:
Attribute

Description

id

Uniquely identifies the business event or message in TRMSwift. It is
also used to access the base XML related to the message (see
12.3.2.4 Original data of the message on page 134).

context

Determines the element on which rules or actions are performed.

context_type

The type of the context, for example, workflow.

owner

The owner of the message. This is the unique name of the adapter
from which the message was received.

ownertype

The owner type of the message. This is the content of the
 tag as produced by the Inbound Message Handler.

reference

The reference with which the message was received.
If the adapter picks up transactions from TRM, the reference
number is the transaction number (from the transaction table).
If the adapter picks up payments from TRM, the reference number is
the transaction number (from the payment table) or 0 if it is a
netted payment. This is followed by a minus sign (-) together with
the payment id (id from the payment table).

state

The state of the message (this is the same as the state of the
workflow element).

stamp

A string representation of the timestamp of the message.

elementtype

132

The type of state element:
•

businessevent

•

message.

© Wall Street Systems IPH AB - Confidential

Constructed XML

Attribute

Description

systemflagsi,
userflagsi,
systemflags,
userflags,
allflags and 

The various system or user flags that are set at the time that the
XML is constructed:
•

systemflagsi and userflagsi: represent the integer value

•

systemflags and userflags: represent a comma separated string
of the unique name of the flags

•

allflags: represents a comma separated string of all the flags
from either set (system or user)

•

 sub-tag: each flag (system or user) is represented as a
sub-tag of  so that it can be used for XPath expressions.

creationdate

The date the message was created.

modificationdate

The date of the last modification.

Constructed XML for administrative data





.
.

The context and context_type attributes enable messages to be formatted according to the
adapter to which the message is being sent, for example SWIFT or Telex. See the table on page 129
for more information on context and context types.

12.3.2.2 Keys and values
Keys and values enable the encoder or Message Monitor to extract values from a message.
Constructed XML for keys and values



123-456
2243
100000.00
2002-04-28 00:00:00
USD

SWIFT Connectivity Guide

133

Constructed XML



.
.

See 12.3.1.2 Keys and values on page 130 for more information on the  tag.

12.3.2.3 Message failure received from CASmf
When a NAK is received from CASmf, data is placed in the feederfeedback section of the message.
Feederfeedback

.




REPORT
fail
TRANSMIS_REP
0





.


12.3.2.4 Original data of the message
When the Business Event Splitter splits a business event into various messages, it creates data that
is assigned to the message and data that is assigned to the sequence. Administrative data, such as
sender, receiver, and message type is stored with the message. Business data is kept in the
sequence (see below for information on sequence data).
Constructed XML for original data (base data)

MT300
SWIFT
NEW
PORTOWNR
CNTRPRTY
.
.


12.3.2.5 Sequence data
A sequence represents the relationship between a message and its associated business event. The
sequence contains business data which is assigned by the Business Event Splitter.
Constructed XML for sequence data

134

© Wall Street Systems IPH AB - Confidential

Rules


id=”124”
.
.
CNTRPRTY


123-456
2243
100000.00
2002-04-28 00:00:00
USD

2001-02-03
1000000
.
.

.
.


Each sequence is identified by the  tag. The sequence attributes contain the ids to the
sequence (sequenceID), the related business event (businessEventID), and message (messageID).
Sequence data is defined after the  tag.
The  tag contains a list of keys and their associated values. See 12.3.1.2 on page 130 for
more information on the  tag.
Additional  tags define sequences for merged messages.

Important: A value for SequenceID must always be supplied. A NULL value is not permitted, and
will adversely affect TRMSwift’s internal processing.

12.4 Rules
As TRMSwift uses XML to store data, it cannot use rules in the same way as TRM. TRMSwift uses
XPath expressions to determine if a business event or message adheres to a particular condition.

12.4.1 XPath expressions
XPath expressions extract a subset of data from the XML. This XML is pattern matched with a
condition, resulting in a boolean value. The XML is often used in conjunction with either the state or
flags of the business event or message. For example, Workflow Deciders check the state, flags and
XPath expression to determine whether a condition is satisfied.

12.4.2 XPath rules
XPath rules are prioritized according to their order ids. When a component needs to perform an
action, it evaluates the rules according to the priority until a rule is matched. The matched rule
indicates which action is performed.

SWIFT Connectivity Guide

135

Rules

Each component in TRMSwift has its own unique set of rules. When the action is performed, it
normally uses the constructed XML. The following components use the constructed XML:

•

Message Monitor

•

Outbound Message Handler

•

Encoder

•

Reconciliator

•

Business Event Notifyer

•

Business Event Splitter (even though parts of the constructed XML are not defined)

The adapter and Inbound Message Handler do not use constructed XML.
The definition of a rule is the same, irrespective of whether it is constructed XML. Rules are defined
using the  tag.
Rule Definition

BES_MT100202
100
/businessevent/businessevent[betype="Payment"]
[transfer_type="MT100202"]
BES_MT100202
BusinessEventSplitter
2001-01-01
2001-12-31


The following table describes the  sub-tags:
Tag

Description
name

The unique name of the rule.

order_id

Determines the priority of the rule.

xpath

The XPath expression for the rule. The expression is automatically
replaced with XML by an editor.

action

The action that is performed if the rule is true. A rule can only
enable a single action to be performed.

component_name The name of the component to which the rule belongs.
active_from

The date from which the rule is valid. Used in conjunction with the
active_to date. For a rule to be valid, the current date must be
within the range specified. The range is inclusive, so the current
date can be equal to the active_from or active_to date.

active_to

The date from which the rule is active.

You can define more than one rule to perform the same action and specify different conditions for
each of the rules. This is equivalent to a logical OR condition for rules. However, you cannot define
rules with a logical AND condition but you may define rules that contain multiple AND, OR and NOT
conditions. The logic must adhere to the XPath standard.
You do this using the  element. You define data that is common to the rules as attributes
of the ruleset element, rather than repeating the data for each rule. This applies to action and
component_name.
The following example shows one rule that is valid indefinitely and another that is valid indefinitely
but only from 1st January 2004.

136

© Wall Street Systems IPH AB - Confidential

Actions

Ruleset Definition


BES_NEW_AMEND_1_LEGGED_PAYMENT
100
...




BES_NEW_AMEND_1_LEGGED_PAYMENT_SECURITIES
100
...
2004-01-01




12.5 Actions
Actions determine the set of instructions that an TRMSwift component performs on a business event
or message. Each TRMSwift component requires a different set of instructions. For example, the
Business Event Splitter needs to establish which messages to create for a business event and what
data to put in those messages. Similarly, the Encoder needs to create well-formatted messages and
determine message data.
The input and output for an action is different for each component. The input for an action is
described in the sections that follow. For more information on output from actions, see Chapter 13
on page 147.

12.5.1 Encoder actions
Encoder actions transform constructed XML from a business event or message into:

•

data that is required to send the message

•

a well-formatted message.

The resulting XML is used by the Outbound Message Handler to send the message to an adapter or
by Message Monitor to preview the message.
The encoded XML is placed in a single 
 element. The data used to send the message is
placed in a  element and the well-formatted message is placed in a 
element.
The XML below shows an example of the final output:
Encoded XML with a well-formatted message


MT300
SWIFT
NEW
PORTOWNR
CNTRPRTY
F01PRTFOWNRABCX0000000000
I300CNTRPRTYABCXN2020

SWIFT Connectivity Guide

137

Actions


1234-34
NOREF
20010203USD1000000,
.
.

.
.

{1:F01PRTFOWNRABCX0000000000}
{2:I300CNTRPRTYABCXN2020}
{4:
:20:1234-34
:21:NOREF
:35B:20010203USD1000000,
.
.
-}

.
.

The  element contains information about the message, for example, sender, receiver,
and fax number to which the message must be sent. The message element also contains a
 element. The sequenceID and message data is used by the Outbound Message
Handler to update the message and sequence with the data to be sent to an adapter. The
sequenceID is also used to create a preview of the message in Message Monitor. Additional preview
data can be placed in a  element. The order attribute identifies particular fields. In a
free-format message, the order id determines the position of a field.

The  element contains the well-formatted message. The well-formatted message is a
text string used as the final message. It is correctly formatted, for example line breaks in the right
place, and only contains permitted characters.

Important: A value for SequenceID must always be supplied. A NULL value is not permitted, and
will adversely affect TRMSwift’s internal processing.

12.5.2 Multiple actions
Generally, XML blocks are only transformed once. Within TRMSwift, there are occasions when XML is
transformed more than once, such as when an action is used in more than one situation. For
example, when encoding an action for MT202 and MT210, the first transformation determines the
receiver (here the logic is the same) and the second transformation creates the required payment
message (here the logic is different).
With the standard Xalan transformers this re-transformation is not possible. Instead, TRMSwift uses
template lists for re-transforming XML blocks.

12.5.2.1 Template lists
A template list is an action that produces a block of XML rather than transforming the XML. The
template list enables multiple action to be run against the XML.
Template List




138

© Wall Street Systems IPH AB - Confidential

Actions


The  element identifies the list of actions to perform. The