Verksamhetsanpassning av IT- baserat finanssystem
Business Configuration of IT-based Treasury System
Lisa Fors
Examensarbete inom teknik och management Kandidat
Degree Project in Engineering and Management
Stockholm, Sweden 2012 Kurs IK120X, 15hp
TRITA-ICT-EX-2012:51
1
Abstract
If P&C Insurance Company faces a challenge when their treasury system needs a new interface to a software as a service application. They need a suggestion for configuration for how the system and the application can work together. The work presented in this report is a suggestion for how you can make business
configuration of an IT-based Treasury System in general. The exact configuration for the case received from If is presented as a separate report, found in Appendix A and is called the If-report. The If-report presents the suggested technical set-up of the configuration. It is not company specific but system and application
specific. The work made in that report will be a standard in future version of the treasury system. The work made in this report is presented to the Royal Institute of Technology and can work as an example of how to approach a business configuration that needs to be done in an IT-based Treasury System.
Keywords: WallStreet Suite (WSS), Currency Linked Systems (CLS), Back office, Properties
Sammanfattning
If Skadeförsäkring står inför en utmaning när deras förvaltningssystem behöver ett nytt interface till en service applikation. De behöver ett förslag till hur deras system kan konfigureras för att fungera ihop med applikationen. Arbetet som presenteras i den här rapporten är ett förslag till hur en konfigurering av ett IT- baserat förvaltningssystem kan göras på ett generellt sätt. Den exakta konfigureringen för det här fallet från If presenteras i en separat rapport som återfinns i Appendix A, kallad ”If-report”. If-rapporten presenterar ett förslag på hur den tekniska konfigureringen kan göras. Den är inte specifik för If men däremot för det system och den applikation som använts. Arbetet som har gjorts för If rapporten kommer att bli standard i framtida versioner av förvaltningssystemet. Arbetet som har gjort för denna rapport presenteras till Kungliga Tekniska Högskolan och kan fungera som ett exempel på hur man går till väga när man ska göra en konfigurering i ett IT-baserat förvaltningssystem.
Nyckelord: WallStreet Suite (WSS), Currency Linked Systems (CLS), Back office, Properties
2
Business Configuration of IT-based Treasury System
At If P&C Insurance Company with mentor Anders Eriksson
At the Royal Institute of Technology with instructor and examiner Anders Sjögren
Bachelor Thesis in ERP-Systems (15 ECTS Credits), Degree Project in
Engineering and Management year 2012 at the Royal Institute of Technology (KTH)
Verksamhetsanpassning av IT-baserat Finanssystem
På If Skadeförsäkring med mentor Anders Eriksson
På Kungliga Tekniska Högskolan med handledare Anders Sjögren
Kandidatuppsats Affärssystemprogrammet (15hp), Examensarbete i teknik och management år 2012 för Kungliga Tekniska Högskolan (KTH)
Version 1.6
2012-03-12 Lisa Fors
3
Table of content
Abstract ... 1
Sammanfattning ... 1
Acknowledgment ... 5
Suggestion for reader ... 5
1. Introduction ... 6
1.1 Background ... 6
1.2 Task and objectives ... 6
Purpose ... 6
Goal ... 6
Scope and limitations ... 7
1.3 Expected outcome ... 7
2 Extended background ... 9
Model ... 9
The Insurance Company’s model ... 9
Object oriented analysis and design ... 10
Discussion ... 10
Previous work ... 11
3 Method ... 11
Fact collection ... 12
4 Implementation and results ... 13
About CLS ... 13
Workflow ... 14
Today ... 14
Tomorrow... 18
Controlling the flow in WSS ... 19
File formats ... 22
Additional requirements ... 23
Analysis ... 23
5 Discussion ... 23
5.1 Conclusions ... 24
Generalization of result ... 25
5.2 Future work ... 25
To be provided ... 25
Suggestions for improvement ... 26
4
Terminology ... 26
References ... 31
Extended references ... 31
Attachment A The If-report ... 32
Attachment B File format MT304 ... 60
5
Acknowledgment
The process of writing this thesis has involved and engaged several persons. First I would like to thank the Royal Institute of Technology (KTH), and my instructor Anders Sjögren for accepting my thesis and giving me invaluable feedback. I would also like to thank Gudrun Jeppesen at Stockholm University (SU) for her initial feedback in the start of the process.
Thanks also to If P&C Insurance Company for giving me the opportunity to write this thesis. My mentor at If, Anders Eriksson, has been a great help and support during this process. To be able to work with him and learn from him has been the greatest value of this thesis. My coworkers and boss at If has also shown great support and understanding – thank you.
Last but not least I would like to thank my family for their endless support in whatever I do.
Suggestion for reader
I recommend readers to this report who are not familiar with financial terms, the application Currency Linked System and the system WallStreet Suite to read the Terminology chapter before anything else in this report.
6
1. Introduction
1.1 Background
The Insurance Company is in need of a documentation of how an interface for their software as a service application Currency Linked Systems (CLS) can be used together with their IT based Treasury-system WallStreet Suite v7.4 (WSS). CLS is a confirmation and settlement system for trades made in the foreign exchange market. It automates the process of confirming and executing trades made by brokers in a secure way. For that, CLS is widely appreciated and used by banks and financial institutions all over the world.
In order for the Insurance Company to be able to use it, they need an interface to their treasury system WSS. The report written for If should not be confused with this report, written for KTH. The original report that was handed over to If is in this report found as Appendix A, it will be referred to as the If- report.
The If-report will, if successful, be handed over to WallStreet Systems, the provider of WSS, for them to develop. The assignment is to write a documentation which should serve as a suggestion for how the interface can be configured.
1.2 Task and objectives
Purpose
The purpose is to automate the manual settlement and confirmations process of foreign exchange trades (FX trades) for back office.
Goal
The main goal of this documentation is to present a suggestion for a business configuration that later can be implemented in the treasury system. This requires following:
- A method that is familiar to the Insurance company - A configuration that applies to any company using WSS
- A naming convention that is similar to other interfaces used in the treasury system
These goals will help fulfill the main goal and have been declared by the Insurance Company.
7 Scope and limitations
The specification should be written according to model that the Insurance Company’s used in earlier reports. The report should mainly explain how WSS should be set-up and integrate with CLS to give the best end-user experience. It should be written in a way that it can apply to any company using WSS v. 7.4 together with CLS. Therefore, no company specific info should be shown in the report.
The report should be limited to contain the set-up that the Insurance Company had in earlier version of WSS, that is, only for fx-spot, fx-forward, fx-swap trades (see Termonlogy chapter). That means that nothing should be specified for fx-options and non-deliverable forwards (NDFs) at this stage. This info is not company specific but general as it only concerns what instruments that are most widely traded in CLS.
1.3 Expected outcome
The following headings explain what the outline of the If-report should contain.
Background
Explains shortly why the specification is needed and what purpose it serves.
About CLS
This chapter explains more about CLS and the use of it when you also use WSS.
Workflow
The process models show how the workflow at the insurance Company was done before and after the use of CLS. They show both the confirmation and the settlement workflow to distinguish the different
processes.
Controlling the flow in WSS
This chapter explains how WSS should be configured if the interface is built. It also explains how the set- ups work and the logic behind it.
Property editor
In this chapter the properties needed for different objects are stated. The properties are set-up in an editor called “Property editor” and later added to the different objects.
8 Transaction tags
In this chapter the set-up of transaction tags in WSS is explained. The logic and conditions for the tags are also explained.
Activity Manager
This chapter explains how the application Activity Manager in WSS should be set-up.
Transaction Flow
This more in-depth chapter explains exactly what happens to a transaction when it moves in the
transaction flow in WSS. It explains in what transaction state a transaction is and what the outcomes of actions would be from that state. This chapter justifies the set-up.
Suggestions for improvement
In this chapter suggestions for improvements are stated. They are ideas that might have come up during the work or things that were excluded because of limitations.
To be provided
This chapter shortly explains what the insurance Company later will provide to WallStreet Systems. This has been excluded from the original specification because of lack of time and priorities the build the most critical parts first.
Attachment 1
This picture explains how the file should look like in order for CLS to be able to read it. It also explains from where the file should get the data in its fields.
9
2 Extended background
Model
When approaching this documentation I compared two models, the model provided by the Insurance Company and a general way of work called object oriented analysis and design. I present these two below as well as a discussion where they are compared.
The Insurance Company’s model
The Insurance Company model was provided by my mentor Anders Eriksson. He has previously written a report for another system (Central trade manager - CTM) and asked for the same outline for this report for CLS. The CTM report was written according to this model:
Background About CTM
Interface between WSS and CTM Workflow today and tomorrow Controlling the flow in WSS
Transaction Statuses (new version calls statuses – tags) Transaction Parameters
Property Editor Activity Manager Transaction Hook Rule editor Transaction Flow Modes
File formats for export and import (as an attachment) Additional Requirements (Suggestions for improvement)
This model first explains the background (purpose) of the report. It then provides some short basic information about the system and the workflow where it will be used. Then it describes the technical set- up and the logic required, written in a way that only a person with good knowledge about the WSS can understand it. The transaction flow part describes how the set-up will work and can later be used as a foundation for acceptance testing. After that the file formats are described and this is also done on a quite high level where previous experience/knowledge about WSS is needed. At the end the additional
requirements are presented, this is to be done later or suggestions for improvement to the company which will build the specification. All headings under “Controlling the flow in WSS” are not mandatory as some of them don’t apply to an interface with CLS; these are marked with cursive writing.
10 Object oriented analysis and design
Work with Object oriented analysis and design (OOA/D) can be done in many ways. However most models can be drawn down to:
Identifying usage scenarios for the system Describe interactions between user and system
Assigning responsibility for the outcomes to parts of the system
To be able to identify scenarios and users for the system interviews can be conducted. Then different kind of diagrams can be helpful in sorting out the information. To mention a few, use cases, sequence
diagrams, class diagrams and filmstrips. The interaction between the user and the scenarios can be
identified as interaction. This will be done for different business processes. In the end, we need to find the outcomes of these interactions. For all interactions an outcome should be specified. For example a user can be identified as “Back office” which should be able to run (scenario) an activity which exports a file (interaction). The outcome of this interaction should be that the file is successfully sent to CLS and
updated in the systems as “CLS-Sent”. Possible changes of objects should also be specified and connected to other objects. By doing that you might save time by having a common changed object connected to several other objects, instead doing one for each one of them.
A class diagram should be written to identify different classes which are connected to each other and contain info. To explain more about the technical structure and architecture component and deployment diagrams can be written. They explain more in detail what the structure look like (through pictures) and how they work (through info in the pictures) (Gorman, 2005).
Discussion
The OOA/D is a well-known and used model. It is used in several courses at KTH where diagrams such as class diagrams and use cases are often written. This is a very structured way to work and makes it easy for other people (without previous knowledge) to understand and follow the work. The programmers get’s an overview of what is needed but they also need to do some thinking of their own to be able to build the system. The Insurance Company’s model is more technical and assumes the reader have good knowledge about the system and workflows. It might be easier for a programmer to implement but harder for an end- user to understand. However, the Insurance Company has already written a specification with their own
11 model and wants to continue to do so. They are familiar with the model and also with the systems. It won’t be read by others then programmers and system specialists.
Previous work
As CLS has been used together with WSS in an earlier version there is a report for that interface. It has been written by an external Company which the Insurance Company no longer cooperates with. Therefore the If-report could not look anything like their report - that would have been plagiarism.
A business specification has also been written for another system, called CTM Omgeo. The interface for CTM and the earlier version of WSS is already in use and in the new version of WSS as a standard interface. Therefore I studied the set-up and learned the logic to be able to re-create a similar solution for CLS. Even though they are different systems some things can be shared, like the outline of the mode, naming convention and some of the logic. As the interface for CTM is already in use the end-users are familiar with the way it works and the logic behind it, therefore the CLS interface needed to be designed in a way that makes it easy for the end-user to learn and work with it.
3 Method
The method I have worked with is the model that If provided. I choose to work by their method but compromised by drawing four detailed models to better explain the workflows in a well-known language called business process modeling (BPMN), this might be helpful if someone not familiar with the systems wants to learn more.
The most helpful material I used was another report written by my mentor. That report was for another interface for another system but helped in what approach I should take in the beginning. My mentor wrote it without using a specific model or method but only his experience from working several years within the WSS community. He wanted the If-report to be written in the same way in order to make it easier to understand. I think my mentor’s report was written in a structured and logical way, therefore I see no reason for using other methods or models.
The report was done by first reading and going over literature relating to CLS or WSS, then designing the report, then discussion of the result and in the end writing the conclusions.
12 The approach taken writing the report was first extensive reading and research. Much of this was provided by the Insurance Company but to stay current a lot of reading was done online. Websites I used the most was CLS own website, cls-group.com. When the facts were collected I analyzed it and asked questions if there were anything that was unclear.
One goal was to have similar naming convention in my specification as in my mentors. That would make it easier for the end-user and create a more transparent interface. As questions arisen I discussed them with my mentor. I then created a layout of the report. This was done with headlines and key-words. The key-words were helpful as they made me realize the extent of the report and where I needed to research more. I first started to work on the set-up of the system. When I thought all the logic was in place I created a transaction flow where I tested that my set-up would work theoretically. This was done in a first draft for which a received feedback from my mentor by notes and comments. I corrected, added less vital parts like process models and suggestions for improvement and handed in a second draft. This draft was after some more feedback the final draft.
Fact collection
The facts presented in this specification are collected through observation, reading and my mentor. By observing and finding my way around WSS in the purpose of CLS I found new things and learned about new areas. When I lacked information or understanding when working in WSS I used the extensive user manual. From the user manual I learned about the new features in WSS versus the ones that were used in the previous version. I also read the business specification written by my mentor for the system CTM.
From that I learned about the model and also the way another interface was set-up in the system. When questions arise my mentor was always available to answer them and give me feedback. I also searched the web for the latest info about CLS and to learn about different message formats used in file transfers. My mentor reviewed my work two times and gave comments which also worked as a source of information.
His experience and knowledge about WSS was my greatest resource. Looking at the Insurance Company model I collected facts by:
Background The background was written through information
told by my mentor.
About CLS The facts presented here are from the CLS
Group’s website and from own user experience.
13 Workflow today and tomorrow The workflows were written from own experience
of back office work and from information given by my mentor.
Controlling the flow in WSS
Transaction Statuses (new version calls statuses – tags)
Transaction Parameters Property Editor
Activity Manager Transaction Flow Modes
The controlling the flow section is the most complex. Here I used basic understanding from WSS together with research about the new version through user manuals and my mentor. The name of the tags, parameters and properties were taken from the specification for CTM, as the names should be similar. Some parts were created through discussions and brainstorming with my mentor. Most ideas to the set-up that we presented were very changed several times during the work as I gained greater understanding of the logic with time.
File formats for export and import The file formats were created from material about the formats from If and from internet. The
message formats are standardized and are used by banks and institutions all over the world, therefore a lot of information about the fields in the files and their meaning can be found online.
Additional Requirements (Suggestions for improvement)
The additional requirements were written in the end of the specification when I had good
understating of both WSS and CLS. This section also contains some limitations as “future work”.
4 Implementation and results
The results of the report contains of the suggested technical configuration in WSS. It is presented in the Insurance Company’s model which you can follow by the name of the headings. The background has been excluded since it is explained in this report as well as found under heading “Background” in Appendix A.
About CLS
CLS stands for currency linked system and is used for confirmation and settlement of foreign exchange trades. It offers a way to eliminate the settlement risk through payment versus payment (payments are made to involved parties at the same time). CLS is the market standard for FX settlements and is used by 13 441 banks, corporates and funds (CLS-Group, 2011). Today 17 currencies are eligible for use in CLS.
It performed as a file transfer between the customers’ treasury systems and CLS. When both
counterparties has sent in their trades in files to CLS (or input them directly in the system) CLS checks the trade details and if correct replies with a file to the customers.
14 Workflow
The work-flow of the Insurance Company today is presented here to show the difference in the business processes if the proposed configuration is accepted and implemented. The end of the confirmations flow is the start of the settlement flow.
Today
Confirmations flow
The confirmations flow explains the trades flow from it is input until it is confirmed in WSS. It is done to make sure the trader has input correct details in the system. The confirmation is done between yourself and the counterparty you traded with. The trade details are compared and back office makes sure everything coincide. In case something differs back office first talk to their trader and asks if he input something wrong, if not the counterparty is contacted. Without the use of CLS this is done mainly by fax, with CLS the comparing is done automatically. Before CLS was used the confirmations flow was done according to this process model:
Front office Back office
Figure 1. Confirmations flow pre-CLS
Back office:
The back office at the Insurance Company makes sure that the trades front office does are confirmed and settled. They also do daily and monthly reconciliations and payments. They use CLS as an application as a service, where they see the trades in a web interface. CLS also integrates with WSS through file transfers.
Wait for fax 0-24h
Yes
Counterparty No
We
Input trade Send trade
to final Compare
trade to fax
Investigate
Fax CP
Trade ok?
Fax CP
Corre ction?
Correct trade
15 Input trade:
The trader inputs the trade in deal capture (WSS v 6.5).
Compare trade to fax: Back office waits for 0.5-24h for a fax from the counterparty, when the fax arrives they compare it to the deal in the system. They mark the fax with “checks” at all important fields.
Trade ok?:
If all important fields correspond BO signs the fax from the CP and faxes it back to them. They then press the “Final” button in back office verification. If the fields don’t correspond further investigation is needed.
Investigate:
BO checks with the trader if he made a mistake, otherwise the trader contacts the CP.
Correction?:
If our trader input the trade wrong the trade is sent back to him in the system.
If the CP was wrong, they correct it and send a new fax.
Correct trade:
Our trader corrects whatever was wrong with the trade. The process then starts all over; as the fax is already received the waiting time is 0h.
Send trade to final:
The trade is in the system sent to state “Final” which is the final state for a transaction. This means that it has been fully confirmed and is ready to be paid. Now the Settlement flow follows.
16
Generate payments
Pay today?
Print fax Payment instructions
Confirm amounts
Send fax to own bank
Check received fax
Fax ok?
Money paid/received
Payme nt ok?
Contact bank
Investigate
Investigate
No
Yes
Yes
Yes
Automatic action
No No
Wait 24h
Settlement flow
The settlement flow explains the confirmed trades flow until it is paid. It is the continuation of the
previous model. Without CLS this is usually done through manual payments to the counterparty. With the use of CLS the payment is done automatically. Before CLS settlement was done according to this process model:
Figure 2. Settlement flow pre-CLS
Generate payments (mode process):
A person in Back office press “Generate” in Settlement manager to generate today’s payments. The payments consist of FX trades in state “Final”. If they have same currency, value date, account and counterparty they are netted. This is done early in the morning.
Pay today?:
If there are no payments due today same procedure is done next day. If there are payments those are shown as netted transactions that are sorted as the user wish.
Print fax:
17 A fax is automatically generated by the system and is printed by the user. The system has fetched payment instructions to the counterparties from Client editor to be printed on the fax.
Confirm amounts:
The user contacts the counterparties and confirms the netted amounts.
Payment ok?:
If the amounts differ and we are have wrong payment details we investigate. If they differ and we are correct we proceed as the payment is OK. If we agree with the counterparty from the beginning we proceed to next task.
Send fax to own bank:
Back office sends the confirmed fax to their bank for them to make the payment/pre-advice.
Check received fax:
The bank replies with a confirmation on the payment/pre-advice.
Fax ok?:
If the fax received from the bank states that the payment/pre-advice has been made money will later be paid/received. If the fax states that the payment/pre-advice hasn’t been made Back office needs to contact the bank and investigate before the money is paid/received.
Money paid/received:
Back office checks the account to see that the money has been paid/received.
18 Tomorrow
If the suggested configuration in the If report is made is implemented in WSS the confirmations and settlement flow will change to a more automated workflow.
Confirmations flow
Export trade file Import trade file
Front office Back office
Figure 3. Confirmations flow post-CLS
Input trade:
The trader inputs the trade in deal capture (WSS v 7.4).
Trade ok?:
The export activity is run automatically and transports the trade file to CLS. It later automatically imports trade files. Back office then checks in back office verification if there are trades there that haven’t been exported/imported. If the trades are OK they have already automatically been sent to state “Final”. If they are not OK, further investigation is needed.
Investigate:
BO checks with the trader if he made a mistake, otherwise the trader contacts the CP.
Yes
Counterparty No
We Input trade
Investigate Trade
ok?
Corre ction Correct
trade
19 Correction?:
If our trader input the trade wrong the trade is sent back to him in the system. If the CP was wrong, they correct it and send it directly to CLS.
Correct trade: Our trader corrects whatever was wrong with the trade. The trade is automatically sent to CLS through the export activity.
Settlement flow
The settlement flow is the continuation of the previous model where the trade has been confirmed. The settlement flow explains the payment process of the confirmed trade.
1 2
Figure 4. Settlement flow post-CLS
In this scenario two third parties makes a deal with each other. The deal info is sent to the settlement member in an agreed format. The settlement member forwards the deal info in an export file to CLS. If the deal info is same from both parties the trades matched. The matched info is sent back to the settlement member and then to the third party. The payment is later made payment versus payment to the settlement member.
Controlling the flow in WSS
To make the business configuration possible several configurations and features needs to be implemented.
These are described briefly in this report and more in-depth in Appendix A.
20 Properties
Properties are used in the system on different objects as Clients, Currencies and Instruments etc. They are a part of the static data and are therefore not used very often after the initial set-up. The properties decide if the objects should be a part of the interface or not. These properties are not in the system today and therefore needs to be created by the developing company. When they are developed they should be individually added to the different objects. The naming convention of the properties is similar to other interface properties.
To see the full configuration of the properties see Appendix A “Property editor”.
Example of a property:
The object “Client” which in the system is If and all of If’s counterparties (the clients they trade with) should have a property explaining what instruments they can settle via CLS.
CLS-ASSET-CLASS-FX CLS-ASSET CLASS-NDF CLS-ASSET-CLASS-OPTION Value: Yes/No
All clients that are active in the FX market should have this property with value “Yes” to specify what instruments they process via CLS. If a Client lacks an asset property or has a property with value “No” it shouldn’t be possible to trade that asset with or for this client via CLS.
Transaction tags
Transaction tags are used in the system on transactions to show if they are eligible for certain actions or to show that an action has taken part which involved this transaction. They show the end-user what needs to be done and what has happened with the transaction. These are put on or cleared “in the flow” of a transaction through a scripts which means that if a certain action takes place a tag can be set or cleared.
The naming convention of the tags is similar to other tag names that currently exist in WSS.
Example of a tag:
21 The tag CLS-Eligible is set on a transaction if certain conditions are fulfilled. Notice that one of these conditions is the property “CLS-ASSET-CLASS” shown above under “Properties”. The full configuration of the tags and the explanation of all conditions can be found in Appendix A under heading “Transaction tags”.
CLS-Eligible
A transaction gets this tag when the trader press “Apply”. Some conditions needs to be fulfilled in order for the transaction to get this tag. If it does not get this tag or the CLS-Eligible-Only- Forward-Leg tag the transaction cannot go to CLS.
Transaction get this tag if:
Both currencies has property CLS-CURRENCY = YES
Both currencies are not CLS-EXCEPTION-CURRENCIES on portfolio owner or counterparty
Client has property CLS-NODE
Portfolio owner, Counterparty and instrument of the trade all have same value in CLS-ASSET-CLASS
Counterparty has property CLS-BIC Portfolio owner has property CLS-BIC
Leg group 2: Value date ≠ Opening date OR no leg group 2 exist
Activity Manager
Two new activities are needed in order to export/import transactions from/to WSS. The transaction is sent in a certain file format which gets its information from the transaction and different object with certain properties. It is also imported in a certain format which WSS can accept. Both the export and the import activity can put on and clear tags to show what stage the transaction is in or trigger an action. See the full description of activities in Appendix A under heading “Activity Manager”.
Transaction Flow – State flow
The transaction flow is a validation of the suggested configuration. It shows different types of transactions in different stages and with different tags set. It goes through all possible scenarios in WSS and explains what the result should be when actions are taken. This not only works as a validation but also as a help for the developer and as a user acceptance test for the finished product. A simple model was created and shown below is a part of it, the rest can be found in Appendix A under “Transaction Flow”.
22 In the example we follow a trade that is exposed to actions. A trade has been made and is in state “Open”.
The states in the system are, “Open”, “Verify”, “Final” and “Canceled”. More information about states can be found in chapter “Terminology”. A trader then presses “Commit” which triggers a script that put on one tag. Another option is if the trader press “Cancel” which sends the transaction to state “Canceled”.
When the trader has committed the trade it goes to state “Verify”. Here is an example of a tag put on “in the flow”, CLS-Send. If Back office then presses the “Verify” button the outcome will be a popup
message. This model covers not only successful user actions but also scenarios when you press the wrong button when certain tags are put on. This helps the programmer understand the logic of the interface.
Transaction state Transaction Tag Action Outcome Comment
Open Commit Put on tag CLS-
Eligible or CLS- Eligible-Only- Forward-Leg if the criteri is meet.
Transaction is saved in database and sent to state
“Verify”
Open Cancel Transaction is
sent to state Canceled
Verify CLS-Eligible
CLS-Send
Verify Popup message
“Cannot be sent forward in the transaction flow with this tag”
File formats
The file format is for the file exported from WSS to CLS. It is explained in depth in Appendix A, under heading Attachment 1. It explains exactly from where every field in the file gets its data. The format used is a standard format called MT304which is used only for foreign exchange trades. Therefore the names on the fields are standardized and only the mapping needs to be configured.
23 Additional requirements
As additional requirements more configurations are presented which were excluded due to lack of time or limitations of the report.
Analysis
To start with the technical parts of the report made it possible to handle problems early in the process. The creation of the transaction flow made my re-think the set-up and it was a good measure of how well the logic in the suggested configuration worked.
The process models were made in the end of the project. This could’ve been done earlier but due to the lack of time I had to save the non-critical parts to the end. In the end I think it was a great way to finish up the work. I had the most knowledge when the specification was almost done and I wouldn’t have been able to create as good process models in the beginning of the process.
The report was written according to If’s model which I think worked well but can be improved so it can be applied to other business configuration reports. The configuration was done in a way that can be applied to any company using WSS and all names used in the configuration are similar to already existing names.
This will make the work easier for Back office which is shown in the “Tomorrow” process model. This means that the purpose of the report, to automate Back office work, is fulfilled.
An initial weakness of the report was the lack of feedback from several sources. My mentor was the only person providing feedback during the work with the report. However, he is both knowledgeable enough and has the right contacts to quickly discuss uncertainties. The finished report was approved by If and later also approved by the system vendor to be a standard interface. This shows that the finished report and its configuration is both valid and will work in reality.
5 Discussion
The analysis of the report shows two main weaknesses even though the finished report was successful.
The lack of knowledge about CLS can make it hard for If when the configuration later is done. Only one person is knowledgeable enough to test the interface. The report is also written in such way that it can be hard for an end-user that is not familiar with WSS to understand. If these two factors didn’t exist the report would be more valid and also more valuable to If in a learning and developing perspective. The prerequisites for the report unfortunately made this impossible. With more time and resources I believe
24 future business configuration reports can be produced in a more efficient way. This report delivered all the goals, served its purpose and most importantly made the client happy, which in the end is what matters the most.
5.1 Conclusions
The proposed configuration was done in five main areas:
Properties Transaction tags Activity Manager Transaction Flow File formats
These areas are all vital for the configuration to work. The five main areas can be simplified as:
Configuration of static data (properties, transaction tags, activity manager data, file format) The static data is the backbone of the configuration. This needs to be configured correctly in order to be able to create criteria. It is a time consuming area which often changes during the progress of the
configuration. In this area is it necessary to have a good knowledge or have help of someone with good knowledge about the system.
Creation of criteria – how the static data should be used and when
When creating the criteria for the static data it is important to be willing to change both the static data to better fit the criteria and the reversed. Some parts of the static data might not work once the criteria have been created. In this area it is not as important to be knowledgeable about the system, it might be better to have help from an independent person who is able to provide new ways of thinking and then confirm them with a system expert.
Creation of transaction flow – how the criteria works in reality for all possible scenarios
This is the area when the static data and criteria are tested. It is important that nothing in the two previous areas is finalized since it most likely will be further changes made. The transaction flow confirms if the criteria work and how the end user will experience the configuration. It’s helpful here to have several persons looking over the flow since it can be quite large and complicated.
25 All configurations have been made in a non company specific way which makes it possible for other companies to use. Future configuration and limitations has been presented in Appendix A, “Suggestions for improvement” and can work as a basis for a new report or to further build on the If report. All goals for the report have been achieved and when the configuration later is implemented the purpose of the report will be fulfilled.
Generalization of result
The mentor at the Insurance Company approved the work as a working interface. The specification has been handed over to the system vendor for them to build and it will become a standard interface in future versions of WSS.
5.2 Future work
To be provided
For a complete use of CLS together with WSS further documentation needs to be provided. The specification for FX forwards, swaps and same day swaps is written so that options and NDF’s can be used via CLS too. However, separate specifications for those two instruments are needed. Following reports will need to be written:
Report for Options Report for NDF’s
When using CLS for options and NDF’s different file formats are used and the file message looks
different. For NDF’s it will be a continuation on the MT304 attached to this specification. For options the file format MT305 is used. Following documents will later be provided:
File specification MT304 File specification MT305
26 Suggestions for improvement
Several improvements can be made to this business configuration suggestion. The model used should be revaluated and built upon. In the future If might be able to use it as a standardized model.
I think that more employees should be educated in CLS. This would not only help with future
configurations but also to back up my mentor in his work. The configuration itself can be improved in such way that it is more effective and easier understood, however that would not make it similar to other interfaces today which is a disadvantage for the end-user. For exact improvements concerning the configuration see Appendix A “Suggestions for improvement”.
Terminology
Activities
Activities are used in the system to trigger certain actions. When a trade is made and input in the system it is sent to CLS when an automatic activity is ran. The activity looks for trades that should settle in CLS, picks them up and export them in a file to CLS. It is also through an activity that the import file is received.
Amend
To amend a trade in CLS is to overwrite the trade. If you send in a trade which later turns out to be wrong you can send another file (export) and overwrite the mistake. A trade can be amended an infinite number of times.
BIC
BIC – Bank identifier code. A code that identifies a financial institution and is used for automated processing (SWIFT - Search).
Counterparty
The party you enter a trade with. If you buy USD against EUR with Bank A, Bank A is your counterparty in this trade.
Currency Linked System – CLS
27 CLS was launched in 2002 by CLS Group (founded 1997). It is a settlement system which has become the market standard for FX settlement. The brokers send in their trade and the trades are checked against each other. It they match the money will be sent/received on a payment versus payment basis. That means that they money will only be sent/received if the other party in the deal send/receives their money. This minimizes the settlement risk (CLS Group, 2011).
Foreign exchange market
The total foreign exchange market is the largest market in the world. It exists because of the value that is created when currencies are compared to external references (like other currencies). The total foreign exchange market consists of four smaller markets, the spot market, the futures market, the options market and the derivatives market.
The spot market: Exchange of two currencies, normally two days (spot days) after the agreement has been made.
The futures market: The exchange of currencies is set to a future date to a specific rate. It is used to eliminate risk when you expect a payment in another currency than your own, for example your Swedish firm expects 10M USD in two months. If you entered a futures contract where you know you can sell your USD against SEK to a fixed rate you have secured yourself against the risk that the SEK lose value
against the USD.
The options market: An option is a right to buy/sell a currency or a currency future at a specific price in a specific period. You can buy and sell an option (and therefore also the right).
The derivatives market: In this market forward contract, foreign-exchange swaps, forward rate agreements and barrier options are traded (Levinson, 2005).
FX
FX is short for “Foreign Exchange”. Trades made in the foreign exchange market are often referred to as
“FX-trades”.
Fx-forward
An FX instrument that involves two currencies which at an agreed rate are exchanged at an agreed date in the future. This also involves NDF, non deliverable forwards. For NDF’s you net the cash flows of the trade so that only one party of the trade pays (Mallo & Mesny, 2010).
Fx-option
28 A FX option gives you the right to buy/sell two currencies against each other at a specific rate in a specific period. The buyer of the option decides if he wants to execute the option or not. (Mallo & Mesny, 2010)
Fx-spot
A FX instrument that involves two currencies which at an agreed rate are exchanged two business days after the trade was agreed (Mallo & Mesny, 2010).
Fx-swap
A FX instrument that involves two currencies first being traded as an Fx-spot (first leg) and then same currencies are paid back as an Fx-forward (second leg). All details of the trade are agreed when the parties enter the trade. For example, you believe that the EUR will be worth more against the USD in the future (Mallo & Mesny, 2010). On the 01.01.2011 you decide to buy 100k USD/EUR on 03.01.2011 at a rate of 0.73 and then sell 100k USD/EUR on 01.03.2011 at a rate of 0.70.
That means that on the 03.01.2011 you will pay 7 300 EUR and receive 100 000 USD.
On the 01.03.2011 you will pay 100 000 USD and receive 7 000 EUR.
MT304
A message format that is used by third parties to advice or instruct a deal. It is only used for FX trades (excluding options). It provides details about the trade. The message is automatically generated from WSS when an activity has run (SWIFTStandards, 2006).
Opening date
The date when you enter a trade.
Properties
A property in WSS is a way to “mark” different entities with values. For example a currency can have property (be marked with) CLS-CURRENCY with value Yes or No. If the currency is used in CLS it should have value “Yes” if not value “No”. The properties can also work as conditions. For example, a FX trade can only go to CLS if the portfolio owner (If), the counterparty and the instrument all have the same property CLS-ASSET-CLASS-FX. This is to ensure that the right trades are eligible for CLS. If the counterparty don’t do FX trades it shouldn’t be possible to input FX trades (that will go to CLS) with them in the system.
29 Same-day swaps
Same as Fx-swap only that the first leg is settled same day as the trade is made. In other words, for the first leg opening date = value date.
Settlement
Settlement happen when the earlier agreed trade is executed. When a trade has been confirmed the money is exchange on value date. After that your trade is settled. Until value date occurs the trade is not settled.
Settlement member
A settlement member is a bank or corporation which is a member of CLS. They hold an account in CLS and have direct access to the system. The settlement member can provide the CLS service to other banks and corporations.
Third party
A third party is a bank or corporation who uses CLS through a settlement member. The CLS member then inputs the third party instructions and provides them with an interface where they can see their trades in real-time.
Trader
The person who commits to the trade.
Transaction flow
The transaction flow describes the flow of a trade after it has been input in a treasury system. The transaction is input by a trader and is usually confirmed by a Back office before the actual money is exchanged. What system you use and how the confirmation is executed affect the transaction flow. There can be hold-ups like disagreement of agreed rate of the trade etc which delays the flow.
Transaction tags
Tags are used in WSS to recognize specific characteristics of a transaction. For the transaction to get a tag, certain conditions or actions must be taken. For example, for a transaction to get tag CLS-Eligible (means that it can be confirmed and settled through CLS) certain properties must be present at the entities
30 involved in the trade (portfolio owner, currency, counterparty, and instrument). If those properties are present and coincide with each other, the tag is set on the transaction. Other tags, like CLS-Send (which means that it is ready to be sent to CLS) is set only if tag CLS-Eligible is already set. Tag CLS-Sent (means that the transaction has been sent to CLS) is only set if the export activity has run successfully.
Transaction state
A trade in WSS can be in four states. When it’s made by a trade the transaction is in state “Open”. As soon as the trade commits to the trade by pressing the “Commit” button the state changes to “Verify”.
Back office then verifies the trade against the counterparty (this is in CLS made automatically) and then press the “Verify” button. When the trade has been verified it changes state to “Final”. At any state there is also the possibility to press “Cancel” which changes the transaction state to “Canceled”.
Value date
The date when the trade is executed. For FX trades this is when you exchange you money, for example pay USD receive EUR.
WallStreet Systems
WallStreet Systems is the system provider of WSS. They provide solutions for corporate treasury, bank treasury, central banking, FX trading and back office operations (Wall Street Systems, 2011).
WSS
WSS is a treasury system for corporations provided by WallStreet Systems. It works as a strategic enterprise platform where you can control cash management, trading, funding and investment activities automatically and also audit, consolidate and account them (Wall Street Systems, 2011). In the Insurance Company’s treasury department WSS is used by front office (traders), middle office (risk and
performance), back office (settlement and reconciliations) and by accounting.
31
References
CLS Group. (2011). CLS. Retreived from About CLS: http://www.cls-group.com/About/Pages/default.aspx den 7 November 2011
CLS-Group. (08 2011). CLS Information. Retreived from CLS Information - Market Data: www.cls- group.com/Products/Pages/CLSInformation.aspx den 05 10 2011
Gorman, J. (2005). UML for Managers. Parlezuml.com.
Levinson, M. (2005). Guide to Financial Markets. London: The Economist in association with Profile Books LTD.
Mallo, C., & Mesny, P. (2010). Report on global foreign exhange market activity in 2010. Basel: Bank for International Settlements.
SWIFT - Search. (u.d.). Hämtat från SWIFT: https://www2.swift.com/search/redirect.faces 11 10 2011 SWIFTStandards. (1 02 2006). Category 3 Treasury Markets - Foreign Exchange, Money Markets and Derivatives . La Hulpe, Belgium .
Wall Street Systems. (2011). WallStreet Systems. Hämtat från Wallstreet Suite:
http://www.wallstreetsystems.com/products/wallstreet-suite/ den 2011 November 7
Extended references
With the help of a modeling language the If model can be further improved. The reference I used above to J.
Gorman’s book can be helpful when learning about Object oriented analysis and design (OOA/D) and also about the modeling language UML. Business Process Model and Notation (BPMN) can be used to describe workflows and make process models. I recommend these sources to learn more about BPMN:
Chinosi Michele, T. A. (January 2012). BPMN: An introduction to the standard. Journal Computer Standards & Interfaces, Volume 34, Issue 1 .
Object Management Group, Inc. (2 June 2010). Object Management Group Business Process Model and Notation. Hämtat från http://www.omg.org/spec/BPMN/2.0/examples/PDF 12 March 2012
32
Attachment A The If-report
Business specification CLS
WallStreet Suite v 7.4
Lisa Fors
33
Table of contents
Document History ... 34 Background ... 35 About CLS ... 35 Workflow ... 36 Confirmations workflow pre-CLS ... 36 Settlement workflow pre-CLS ... 37 Confirmations workflow post-CLS ... 38 Settlement workflow post-CLS ... 39 Controlling the flow in WSS ... 40 Property editor... 40 Object Client ... 40 Object Portfolio ... 42 Object Currency ... 42 Object Instrument ... 42 Object Activity ... 43 Transaction tags ... 44 Swap specific tags ... 45 Activity Manager ... 46 Transaction flow ... 48 Forward and Spot ... 48 Swaps ... 51 Same day swaps ... 55 Suggestions for improvement ... 59 To be provided ... 59
34
Document History
Version Author Date Description
1.0 Lisa Fors 20110816 First draft
1.1 Lisa Fors 20110819 Update with feedback
from Anders Eriksson
2.0 Lisa Fors 20110824 Second draft
2.1 Lisa Fors 20110829 Second draft after
feedback from Anders Eriksson
3.0 Lisa Fors 20110830 Sent to wallstreet
3.1 Lisa Fors 20110905 Workflow added
35
Background
If and Sampo are upgrading their investment operations system Wall Street Suite v 6.5 to version 7.4. The upgrade will be conducted as a new implementation of the system. CLS, which is a Currency Linked System used for confirming and settle trades made in the FX market, has been working as an application as a service together with version 6.5. With the new implementation If and Sampo will have to develop new functionality in v 7.4 in order to make it work with CLS. New enhancements will be added as well as improvements to make the CLS solution look more like the other application as a service that they use, CTM (Omgeo).
About CLS
Founded in 1997, CLS Group was first to create a global settlement system to eliminate settlement risk in the foreign exchange market. CLS settlement is now the market standard for FX settlements and continues to work for minimizing the risks associated with FX trading. CLS Settlement is offered by CLS Bank, owned by the foreign exchange community, and operates the largest multi-currency cash settlement system. With CLS settlement you can eliminate the settlement risk, settle seventeen currencies, use payment versus payment to settle matched trades and also settle several different instruments like fx-spot, fx-forward, fx- swap, fx-option and Non deliverable forwards (NDF).
36
Workflow
Confirmations workflow pre-CLS
Process model (BPMN) of the Confirmations workflow pre-CLS.
Frontoffice Backoffice
Input trade:
The trader inputs the trade in deal capture (WSS v 6.4).
Compare trade to fax: BackOffice waits for 0.5-24h for a fax from the counterparty, when the fax arrives they compare it to the deal in the system. They mark the fax with “checks” at all important fields.
Trade ok?:
If all important fields correspond BO signs the fax from the CP and fax it back to them. They then press the “Final” button in back office verification. If the fields don’t correspond further investigation is needed.
Investigate:
BO checks with the trader if he made a mistake, otherwise the trader contacts the CP.
Correction?:
If our trader input the trade wrong the trade is sent back to him in the system. If the CP was wrong, they correct it and send a new fax.
Correct trade:
Our trader corrects whatever was wrong with the trade. The process then starts all over; as the fax is already received the waiting time is 0h.
Wait for fax 0-24h
Yes
Counterparty No
We
Input trade Send trade
to final Compare
trade to fax
Investigate
Fax CP
Trade ok?
Fax CP
Corre ction?
Correct trade
37
Generate payments
Pay today?
Print fax Payment instructions
Confirm amounts
Send fax to own bank
Check received fax
Fax ok?
Money paid/received
Payme nt ok?
Contact bank
Investigate
Investigate
No
Yes
Yes
Yes
Automatic action
No No
Wait 24h
Settlement workflow pre-CLS
Process model (BPMN) of the Settlement workflow pre-CLS.
Backoffice
Generate payments (mode process):
A person in BackOffice press “Generate” in Settlement manager to generate today’s payments. The payments consist of FX trades in state “Final”. If they have same currency, value date, account and counterparty they are netted. This is done early in the morning.
Pay today?:
If there are no payments due today same procedure is done next day. If there are payments those are shown as netted transactions that are sorted as the user wish.
Print fax:
A fax is automatically generated by the system and is printed by the user. The system has fetched payment instructions to the counterparties from Client editor to be printed on the fax.
Confirm amounts:
The user contacts the counterparties and confirms the netted amounts.
Payment ok?:
38 If the amounts differ and we are have wrong payment details we investigate. If they differ and we are correct we proceed as the payment is OK. If we agree with the counterparty from the beginning we proceed to next task.
Send fax to own bank:
BackOffice sends the confirmed fax to their bank for them to make the payment/pre-advice.
Check received fax:
The bank replies with a confirmation on the payment/pre-advice.
Fax ok?:
If the fax received from the bank states that the payment/pre-advice has been made money will later be paid/received. If the fax states that the payment/pre-advice hasn’t been made BackOffice needs to contact the bank and investigate before the money is paid/received.
Money paid/received:
BackOffice checks the account to see that the money has been paid/received.
Confirmations workflow post-CLS
Process model (BPMN) of the workflow post-CLS.
Export trade file Import trade file
Frontoffice Backoffice
Input trade:
The trader inputs the trade in deal capture (WSS v 7.4).
Trade ok?:
The export activity is run automatically and transports the trade file to CLS. It later
automatically imports trade files. BO then checks in back office verification if there are trades
Yes
Counterparty No
We Input trade
Investigate Trade
ok?
Corre ction Correct
trade
39 there that haven’t been exported/imported. If the trades are OK they have already automatically been sent to state “Final”. If they are not OK, further investigation is needed.
Investigate:
BO checks with the trader if he made a mistake, otherwise the trader contacts the CP.
Correction?:
If our trader input the trade wrong the trade is sent back to him in the system. If the CP was wrong, they correct it and send it directly to CLS.
Correct trade: Our trader corrects whatever was wrong with the trade. The trade is automatically sent to CLS through the export activity.
Settlement workflow post-CLS
Process model (BPMN) of the workflow post-CLS. When CLS is used BackOffice has no processes for the settlement workflow. Everything is automated; therefore this model explains the settlement flow without interference from BackOffice.
In this scenario two third parties makes a deal with each other. The deal info is sent to the settlement member in an agreed format. The settlement member forwards the deal info in an export file to CLS. If the deal info is same from both parties the trades matched. The matched info is sent back to the
settlement member and then to the third party. The payment is later made payment versus payment to the settlement member.
40
Controlling the flow in WSS
Property editor
Object Client
CLS-ASSET-CLASS-FX CLS-ASSET CLASS-NDF CLS-ASSET-CLASS-OPTION Value: Yes/No
All clients that are active in the FX market should have this property with value “Yes” to specify what instruments they process via CLS. If a Client lacks an asset property or has a property with value “No” it shouldn’t be possible to trade that asset with or for this client via CLS.
CLS-EXCEPTION-CURRENCIES
Value: All CLS currencies should be possible values
Some clients don’t trade with certain currencies even though they are CLS eligible.
If a Client has a value in this property it shouldn’t be possible to do any trades via CLS with the combination of this client and currency.
CLS-BIC
Value: Client BIC
The value of the property decides what BIC that is used in the export file and in the file header.
Depending on if the client is a portfolio owner or counterparty the use of the BIC is different.
If the client is a portfolio owner:
The BIC is used in field :82A: (Party A M BIC of the Customer) in the export file.
The BIC code is used on position 4-12 on the first part of the file header, an example with If P&C Insurances BIC code, IFPCSES1XXX:
{1:F01IFPCSES1XXXX1001100001}
If the client is a counterparty:
The BIC is used in field :87A: (Party B M Counterparty BIC) in the export file.
If the counterparty also lacks CLS-SETTLEMENT-MEMBER-BIC:
Client BIC is is used in field :53A:.
(This means that the counterparty is a settlement member)
CLS-SETTLEMENT-MEMBER-BIC Value: BIC code of CLS member
41 The CLS-SETTLEMENT-MEMBER-BIC property is added to third parties to help populate different fields in the messages sent in the export file.
The property should be added to:
Portfolio owners that are a third party to a settlement member:
The value of CLS-SETTLEMENT-MEMBER-BIC is used in field :57A: in the export file.
The value of CLS-SETTLEMENT-MEMBER-BIC is used in the second part of the export header on position 5-16. An example with Citibank as a settlement member:
{2:I304CITIGB2LXCLSN}
Counterparties that are a third party to a settlement member:
The value of CLS-SETTLEMENT-MEMBER-BIC is used in field :53A: and in the second :57A:.
For counterparties that are a settlement member, only CLS-BIC will be needed.
CLS-NODE
Value: Node number of the Portfolio owner
The node number is specific to every portfolio owner. It is sent to CLS in the first part of the export file header on position 13-22:
{1:F01IFPCSES1XXXX1001100001}
Counterparty
If the client is a counterparty following properties should be added:
CLS-ASSET-CLASS-FX Optional
CLS-ASSET-CLASS-OPTION Optional
CLS-ASSET-CLASS-NDF Optional
CLS-EXCEPTION-CURRENCIES Optional
CLS-BIC Mandatory
If third party to a settlement member:
CLS-SETTLEMENT-MEMBER-BIC Mandatory
Portfolio owner
If the client is a portfolio owner following properties should be added:
CLS-ASSET-CLASS-FX Optional
CLS-ASSET-CLASS-OPTION Optional
CLS-ASSET-CLASS-NDF Optional
CLS-EXCEPTION-CURRENCIES Optional
CLS-BIC Mandatory
CLS-NODE Mandatory
If third party to a settlement member:
CLS-SETTLEMENT-MEMBER-BIC Mandatory
42 Object Portfolio
All properties available for Client should also be available for portfolio. The portfolio properties should be used when a Portfolio owner have more than one fund which
independently trades in the FX market. When a portfolio has CLS properties these should override the properties on the Client.
Object Currency CLS-CURRENCY Value: Yes/No
All CLS eligible currencies should have this property with value “Yes”. If one or two
currencies lacks this property and is used in trades in the FX market they cannot settle via CLS.
Currencies that are CLS eligible as of 31st of August 2011:
AUD – Australian dollar CAD – Canadian dollar DKK – Danish krone EUR – Euro
HKD – Hong Kong dollar ILS – Israeli new shekel JPY – Japanese yen MXN – Mexican peso NZD – New Zealand dollar NOK – Norwegian krone SGD – Singapore dollar ZAR – South African rand KRW – South Korea won SEK – Swedish krona CHF – Swiss franc GBP – Pound sterling USD – United States dollar
Object Instrument
CLS-ASSET-CLASS-FX CLS-ASSET-CLASS-NDF CLS-ASSET-CLASS-OPTION Value: Yes/No
All instruments that can be settled via CLS should have this property. One instrument can only have one property.
43 Object Activity
Export activity properties
Portfolio
Value: Top portfolio + Trading portfolio
This property should enable portfolio specific export in which the user can decide what portfolios to include/exclude.
Type of asset
Value: CLS-ASSET-CLASS-FX CLS-ASSET-CLASS-NDF CLS-ASSET-CLASS-OPTION
This property should enable asset class specific exports.
Transaction number (optional input)
The export-activity should have a field where we can enter transaction number in case we want to run the export for only one transaction.
Export directory:
The export directory should state the path to the directory where PayPlus picks up the file to match it in CLS.
Import activity properties
CLS-BIC
Value: Client BIC
When the import is done and the file is in the import directory is should be possible to choose only one Client BIC to import all messages in the file for that specific BIC. This is so different portfolio owners can import only their trades and exclude other portfolio owners.
Import directory field:
