CalypsoTraining PDF

©2013 Calypso Technology, Inc. All Rights Reserved.
Calypso is a registered trademark of Calypso Technology, Inc. in the United States, European Union, and other jurisdictions. All products and services referenced
herein are either trademarks or registered trademarks of their respective companies. No part of this publication may be reproduced or transmitted in any form
or by any means, including but not limited to, conversion into any electronic format, without the written permission of the copyright holder, application for which
should be addressed to Calypso Technology, Inc.
Introduction to Calypso Back Office
For CALYPSO V13
Training for Intesa Sanpaolo and

Lynx SpA
10-11 September 2013

Purpose of this Training Manual
The Calypso University team has prepared this Training Manual to facilitate your successful transition into using the
Calypso suite of products. It is very important to us that you understand not only the “hows” of using Calypso software
but in most cases the “whys”.This methodolgy will help you to become not only a more proficient user of the software
but will provide you with additional knowledge that will enhance your current skills.
Using the Training Manual

We have made every attempt to ensure that your learning experience using this Training Manual- is enjoyable. To
that end we have developed internal iconology that should facilitate a consistent and easy-to-understand learning
methodology. The iconology is as follows:
Iconology Legend
Monitor - found in task/step portion of manual. It will let you know what screen
you will need to be in to complete the task along with the path to reach the screen.
Notes - generally found to the right side of each page in a grayed out box. It is the
area set aside for you to take notes.
Additional Research - Any additional information or research that is related to

the module subject will be located in the section following this icon.
Comment - Any tips, suggestions or comments will be preceeded by this icon.
Warning- Any terms or information that are important for completing module
objective or that will be part of a review or exam will be preceeded by this icon.
Contents
Course Overview ............................................................................................................................ ii
Course Description .......................................................................................................................... ii
Learning Strategy ............................................................................................................................ iii
Course Competencies ..................................................................................................................... iii
Course Prerequisites ...................................................................................................................... iii
Course Agenda ................................................................................................................................ v
Final Assessment ............................................................................................................................ vi
Module 1: Back Office Overview .................................................................................................... 7
Introduction ........................................................................................................................................ 8
The Importance of the Back Office ................................................................................................. 8
Straight Through Processing ........................................................................................................... 8
1.1 Preliminary Operations Prior to Back Office Interaction ........................................................... 9
Milestones in a Typical Trading Day ............................................................................................... 9
Risks in a Typical Trading Day ....................................................................................................... 10
1.2 Back Office Operational Responsibilities ................................................................................ 13
Daily Operations ........................................................................................................................... 13
Periodic Operations ...................................................................................................................... 15
Module 2: Calypso Design and Architecture ................................................................................. 17
Introduction ...................................................................................................................................... 18
2.1 System Architecture ................................................................................................................ 19
Data Base Layer ............................................................................................................................ 19
Data Server Layer ......................................................................................................................... 19
Event Server Layer ........................................................................................................................ 20
Engines ......................................................................................................................................... 22
Applications .................................................................................................................................. 26
Overall Process Flow ..................................................................................................................... 28
2.2 The Calypso Conceptual Model ............................................................................................... 31
Product ......................................................................................................................................... 31
Trade ............................................................................................................................................ 31
Module 3: Access, Static Data and Reference Data ....................................................................... 33
Introduction ...................................................................................................................................... 34
3.1 Access Permissions .................................................................................................................. 35
Configuring Users and Groups ...................................................................................................... 35
Configuring Groups ....................................................................................................................... 36
Defining Users .............................................................................................................................. 39
Defining Access Permissions ......................................................................................................... 41
Trading Book Rights ...................................................................................................................... 61
Workflow & Task Action Access Rights ......................................................................................... 63
3.2 Static Data .............................................................................................................................. 66
Legal Data ..................................................................................................................................... 66
Agent: Chase ................................................................................................................................. 75
3.3 Reference Data ....................................................................................................................... 77
Module 4: Components of a Trade ............................................................................................... 83
Introduction ...................................................................................................................................... 84
4.1 Trade ....................................................................................................................................... 85
Components of a Trade ................................................................................................................ 85
4.2 Transfer ................................................................................................................................... 89
Delivery Types .............................................................................................................................. 90
Transfer Types .............................................................................................................................. 91
Transfer Category ......................................................................................................................... 92
4.3 Message .................................................................................................................................. 94
4.4 Postings ................................................................................................................................... 97
Module 5: Generation & Breakdown of Components ................................................................... 98
Introduction ...................................................................................................................................... 99
5.1 Explaining the Generation Process ....................................................................................... 100
Transfer ...................................................................................................................................... 100
Message ...................................................................................................................................... 112
Posting ........................................................................................................................................ 124
Module 6: Workflow -‐ Lifecycle of Components .......................................................................... 142
Introduction .................................................................................................................................... 143
6.1 Overview of the Calypso Workflow Process .......................................................................... 144
Preliminary Configuration .......................................................................................................... 144
6.2 General Principles of Workflow ............................................................................................ 146
Workflow Concept ...................................................................................................................... 146
Engines, Events & Workflow ...................................................................................................... 147
Actions vs. Events ....................................................................................................................... 148
Trade Lifecycle ............................................................................................................................ 149
Trade Retrieval ........................................................................................................................... 149
Transfer Lifecycle ........................................................................................................................ 150
Transfer Retrieval ....................................................................................................................... 151
Message Lifecycle ....................................................................................................................... 151
Message Retrieval ...................................................................................................................... 151
6.3 Workflow Configuration ....................................................................................................... 153
Definition .................................................................................................................................... 153
Accessing Existing Workflows ..................................................................................................... 154
Creating Workflow Statuses & Actions using Graph Method ..................................................... 159
Modify/Adjust & Delete Workflow Actions & Statuses with Graph Method ............................. 162
Creating Workflow Using Tabular Configuration ........................................................................ 165
Characteristics of Workflow ....................................................................................................... 167
6.4 Focus on Some Configuration Concepts ................................................................................ 172
Task Creation .............................................................................................................................. 172
Task and STP ............................................................................................................................... 174
Rule Creation .............................................................................................................................. 176
6.5 Workflow and 4-‐Eyes Principle ............................................................................................. 191
Original Workflow ...................................................................................................................... 191
Different User ............................................................................................................................. 191
Manual Authorization ................................................................................................................. 193
Workflow and Access Permissions ............................................................................................. 195
6.6 Transfer and Message Workflow .......................................................................................... 198
Transfer Workflow ...................................................................................................................... 198
Message Workflow ..................................................................................................................... 200
Summary .................................................................................................................................... 202
Module 7: Monitoring and Managing .......................................................................................... 203
Introduction .................................................................................................................................... 204
A Brief Review of Workflow Concepts ........................................................................................ 204
7.1 Task Station Overview .......................................................................................................... 205
7.2 Configuring the Task Station ................................................................................................. 206
Filtering Possibilities for User Configuration .............................................................................. 221
Define Priorities .......................................................................................................................... 226
7.3 Defined Configuration for our Users ..................................................................................... 236
7.4 User Scenarios ....................................................................................................................... 249
Handling Tasks ............................................................................................................................ 249
Using the Back Office Browser ................................................................................................... 264
BO User1 Handling Tasks ............................................................................................................ 265
7.5 Authorization & Audit ............................................................................................................ 292
Quick glimpse of Swap Trade Scenario ....................................................................................... 292
Trade Audit ................................................................................................................................. 296
Audit Report ............................................................................................................................... 297
Audit via Task Station ................................................................................................................. 298
Module 8: Component Reports, Position Monitoring & EOD Scheduled Tasks ............................. 302
Introduction .................................................................................................................................... 303
8.1 Common Features of Reports ............................................................................................... 304
Features Common to all Calypso Reports .................................................................................. 304
8.2 Specific Component Reports ................................................................................................. 311
Trade Browser ............................................................................................................................ 311
Transfer Report .......................................................................................................................... 312
Message Report .......................................................................................................................... 314
8.3 Treasury: Cash and Security Management ........................................................................... 319
Business Logic ............................................................................................................................. 322
Treasury Management ............................................................................................................... 331
8.4 Management of Instruments Held ........................................................................................ 343
Business Logic ............................................................................................................................. 352
Position Keeper .......................................................................................................................... 355
Modifications Liquidation Handling ........................................................................................... 373
8.5 EOD Batch Processing ........................................................................................................... 374
Generic Review of Scheduled Task Setup ................................................................................... 375
Course Exercises ......................................................................................................................... 378
Module 2 Exercises ......................................................................................................................... 379
System Architecture & Trade Design .......................................................................................... 379
Access Permissions, Static and Reference Data ......................................................................... 380
Components of a Trade .............................................................................................................. 383
Generation and Breakdown of Components .............................................................................. 385
Course Overview Introduction to Calypso Back Office
Course Overview
Straight Through Processing at the Speed of Globalization
The Back Office (Operations Department) is responsible for all processing done on all transactions
initiated by the Front Office. The importance and responsibility level of the Back Office has increased
in recent years due to trade volumes, the complexity of the products that are traded, and
centralization of global processing. .
Competitive organizations must focus not only on the P&L generated by the Front, but also on the
financial controls required for cost effective and efficient trade processing in the Back Office.
In order to manage the flow of business, reduce the risk of human error, and increase efficiency within
their organizations, financial institutions have spent a great deal of time and money redefining their
internal infrastructure to support Straight-Through Processing (STP) practices.
With the advance in information technology, deregulation, competition, higher volumes and greater
risk, the number of automated portals and trading systems has grown significantly in recent years.
Calypso’s cross-asset Back Office platform provides STP for all major asset classes: foreign
exchange (cash and derivatives), money market, fixed income, securities finance, interest rate
derivatives, credit derivatives, equities and equity derivatives, commodities and commodity
derivatives, and structured products.
In each of these categories, Calypso covers an extensive range of products from vanilla to complex
through the entire trade lifecycle. The straight-through processing framework is versatile and flexible,
adaptable to any organization’s business processes.
Course Description
The objective of this 2-day course is to provide participants with an in-depth understanding of the
Calypso v13 Back Office components and how they can be configured to meet the needs of various
business users.
This course is an introductory course. Participants will learn the main Back Office components,
review their generation process, dependencies, and implications through the system as the
components move through their lifecycle using Workflows. The course will address the calypso
monitoring and management tools (such as the Task Station, Audit Report, Authorization Report,
Component Reports – Transfer/Message/Posting - as well as Inventory and Liquidation reports).
Throughout the course, participants will partake in exercises as well as gain hands-on experience with
exercises which including studying the foundational Back Office data that is required to be in place,
i.e., setting up: relevant Access Permissions, Reference and Static data (such as Legal Entities,
Contacts, and Settlement & Delivery Instructions), Message Configurations, Workflows and
configurations for Task Station.
In addition, in relevance to Back Office functionality, this course will cover the Calypso v13 and prior
architecture and design (the course uses a couple of Financial Instruments to show how Calypso
handles products).
This course is designed for Calypso clients working in the Back Office, business analysts or partners
who want to understand how to set up the various Back Office components.
ii
Learning Strategy
This course takes a ground-up approach to helping participants learn the Calypso Back Office
functionality. Calypso University instructors use the following instructional framework in order to
provide you with the opportunity to master fundamental Calypso skills:
• One or more presentations for each learning module
• Coaching, guidance, and specific feedback from the instructor regarding correct software use
throughout the course
• A set of practice exercises for each learning module that will be completed by the participant using
his/her own instance of Calypso
• At course completion, participants will be given a final assessment to measure their level of
comprehension and to demonstrate their achievement of course objectives. Participants who
satisfactorily complete the final assessment will be presented with a Calypso University course
completion certificate.
Course Competencies
Upon successful completion, participants will be able to:
• Demonstrate an in-depth understanding of the Back Office functionalities including functional and
non-functional components, setup, and access permissions.
• Configure Settlement and Delivery Instructions for various settlement scenarios involving multiple
currencies and counterparties.
• Configure Calypso Workflow from scratch under standing the different setups for supported product
types.
• Demonstrate proficiency in configuring and using Calypso for managing the various Back Office
functionalities, such as messages, transfers, and postings.
• Configure and use exception handling and batch processing tools such as the Task Station and
Scheduled Tasks.
• Configure various Back Office Reports using the Calypso Reporting Framework.
Course Prerequisites
Calypso University recommends that you have basic business experience with Back Office
operations. We also recommend that you are familiar with Trade capture, static and reference data
such as legal entities and settlement instructions, transfers, Operational lifecycle of trade-based
and/or position-based products, task monitoring, four-eye principles and audit, and various Back
Office reports.
Registered participants of this course are also encouraged to review the following Calypso University
eLearning modules:
• Calypso Basic Introduction –V13
• Doman Values
• Legal Entities
• Trading Books
iii
• Static Data Filters – V12+

• User Defaults
• Settlement Instructions
• Calypso Transfers
• Workflows
• Workflow Rules KO-CO
iv
Course Agenda
Module 1 Back Office Overview

• The role of the Back Office in financial institutions
Day Module 2 Calypso Design and Architecture

1
• Calypso architecture
• Conceptual design of trades in Calypso
• Required standard data
Module 3 Access, Static Data, and Reference Data

• Access Permissions
• Legal Entities
• Legal Agreements
• Trading Books and Accounting Books
Module 4 Components of a Trade

• Sample Trades
• Trade component: Transfers
• Trade component: Messages
Module 5 Generation and Breakdown of Components

Day • Generating transfers: Transfer Engine and Events, Transfer Rules
2
• Settlement and Delivery Instructions
• Generating Messages: Message Engine and Events, Message Configuration
• Legal Entity contact information
• Accounting Postings: Account Engine and Events, link between Accounting

Rules, Books, Events and accounts
Module 6 Workflow – Lifecycle of Components

• Workflow principles
• Workflow Configuration: Straight-Through Processing
• Tasks
• Rules
• Kick-off/Cut-off timers
• Implementing the 4-eyes principle through Workflow
v
Module 7 Monitoring and Managing

• Task Station setup
• Task priority levels
• Distribution of management of tasks of various priorities across users
• Task Activities: Taking ownership, adding comments on underlying objects,

completing on the basis of specific responsibilities
Module 8 Component Reports, Position Monitoring and EOD Scheduled Tasks

• Examine various fields and output of reports: Back Office Inventory, Trade,
Transfer, Message, Posting, Position Keeper, Account Balance
• Describe Scheduled Tasks for EOD jobs
Final Assessment, end of Day 2
Final Assessment
In addition to the hands-on exercises, participants will be given a final assessment in order to measure their
level of comfort in the subjects presented during the two-day course. Participants who satisfactorily complete
the final assessment will receive a Calypso University course completion certificate.
vi
Module 1: Back Office
Overview
By the end of this module, you will be able to:

• Explain the role of Back Office departments in financial institutions
• Identify the events that occur before the Back Office role begins in
a typical financial institution
• Identify the daily and periodic responsibilities of Back Office

departments
MODULE 1 Back Office Overview
Introduction
The Importance of the Back Office
The term Back Office is a market-recognized name for the department in a financial institution that is
responsible for confirming and settling trades transacted by the Front Office. The Back Office
(Operations Department) is responsible for all processing done on all transactions initiated by the
Front Office.
Large trade volumes, the complexity of the products that are traded, and the globalization of the
financial environment have all increased the importance and responsibility levels of Back Office
departments.
Competitive organizations must focus not only on the P&L generated by the Front, but also on the
financial controls required for cost effective and efficient trade processing in the Back Office.
Straight Through Processing

In order to manage the flow of business, reduce the risk of human error, and increase efficiency within
their organizations, financial institutions have spent a great deal of time and money redefining their
internal infrastructure to support Straight-Through-Processing (STP) practices.
With the advance in information technology, deregulation, competition, higher volumes and greater
risk, the number of automated portals and trading systems has grown significantly in recent years.
Depending on the institution, the STP infrastructure is developed and maintained in-house or
outsourced to external vendors or is some combination of both. STP is used from trade input to
settlement/payment or at any point in between.
Trading across products and external vendor process management (i.e., clearing/settlement) has
created a number of external restrictions, cut-offs, and liquidity/cash management regulations that are
stipulated by Clearers and Exchanges. Today, Operations departments must manage the integration
of numerous external and internal systems and requirements.
Matching/confirmation systems such as TRAX (for bonds, derivatives, equities, swaps and much
more) demand that trades are entered within determined minutes of execution; automatic matching
systems managing SWIFT messages have time-outs for un-reconciled items; Clearing firms such as
CLS in the FX Markets have currency cut-offs etc. These are all different demands that must be
managed and executed by Back Office departments.
This is especially true in today’s environment where vast sums of money are involved; trillions of
dollars are settled daily and thus the impact of risk is very high. In addition, more and more financial
institutions offer the same products at similar prices thus the level and quality of service provided by a
bank’s Back Office to its customers and other banks can distinguish it from other banks.
As more and more financial institutions offer the same products at similar prices, after a trade has
been transacted, the level and quality of service provided by a bank’s Back Office to its customers
and other banks (confirmation, reconciliation, payment/settlement, statement generation, matching)
and the other services provided is highly important for the profitability and competitive profile of the
bank.
With all of these elements at play, it is essential that a financial institution has a Back Office operation
department that is exceptionally thorough, providing a fault proof transparent service.
Notes:
1.1 Preliminary Operations Prior to Back Office

Interaction
In this section, we will review the events that take place on a typical day before Operations becomes
involved in a trade. We will us the example of a high-volume OTC derivatives trading desk.
Milestones in a Typical Trading Day

New York 7:00 a.m.-Traders and Trading Assistants begin their day. Traders, for the most part, begin
their day by reviewing spreads on their electronic feeds, calling brokers/market makers to get an idea
of overnight events, and testing hypothetical trades while the Trading Assistants begin by opening
and logging into all their relevant systems/spreadsheets.
Each trader uses an in-house developed blotter to document/account for his/her transactions.
Depending on the size of the institution, this would be an internal platform (especially true for the
bigger institutions) in the form of a spreadsheet shared between all traders that trade on the same
book.
The spreadsheet serves five main purposes:
• It is a point of reference for Trading Assistants to view/ track their trader's activities throughout the
day
• Information from the blotter can be fed into the Trading Assistant’s own blotter
• Trading Assistants can use the information to tie out/reconcile against the market
• The spreadsheet can be used to directly feed derivative tickets and hedges that are on the
trader’s blotters into either the bank’s proprietary interfaces used for their Middle Office and Back
Office management or external vendors (such as Calypso)
• The spreadsheet allows the traders (trading on the same book) to view their book position (Risk &
P&L) in real time
Each morning, before the start of the NY day, in order to make sure that the tying out process
between themselves, the traders, and the brokers/counterparties goes smoothly and to ensure that
the automatic feed into the proprietary systems runs smoothly, it is up to the Trading Assistant to
check that the trader blotter and their own blotter is correctly configured.
As the blotters are, in effect, Excel spreadsheets, it is up to the Trading Assistants to ensure the
following:
• Their curve is updated (to price swap spread trades when confirming broker trades or checking
the coupon on a sale trade)
• Their delta spreadsheet is updating with the correct analytics to price out correct hedge amounts
• Their static data information (such as the correct Excel codes for the 'On the Run' treasuries vs.
codes in internal system as well as the prior days Eurodollar Future closes) are all up-to date
Notes:
Although Trading Assistants have access to the traders’ blotters, they must double-check the blotter
information against what the 'market' knows. For example; If the NY trading book is a global book
(NY/LDN & TKY), the Trading Assistants would initially do the checks for overnight trades.
Assistants also have to review the overnight orders filled for the Tokyo desk and/or the London desk
by verifying/reconciling each order against what brokers/market makers, counterparties have
confirmed via various technology systems (Bloomberg/Reuters emails etc.).
The verification against incoming information serves as a form of confirmation and to double check
the information brokers/counterparties have sent vs. what the trader has input on his/her blotter. In the
early morning this is especially important as the Tokyo traders have most likely left their offices for the
day.
Once reconciled, Trading Assistants can use the blotter to push derivative and hedge orders into the
proprietary systems. If this reconciliation proves there have been any misbookings the Trading
Assistant must update the blotter before launching the feed into the downstream systems.
If misbookings (mostly on hedges) have already been fed into the systems, the Assistant must identify
and manually amend them. Activating the blotter feed into the downstream system results in
launching electronic tickets for derivatives tracked by the Middle Office/Audit departments.
By 7:30 A.M, NY trading on the OTC desk begins with correct positions. These positions would
include the half-day London activities. Traders will transact Swap trades throughout the day against
which bonds or futures will be bought or sold to hedge positions.
Swaps orders are filled in one of several ways. The trader uses the Sales Desk, a broker or they can
transact the Swap order against another trading desk. Bonds are either transacted with the broker
that filled the Swap Order (thus against the same Counterparty) or the internal
treasury/mortgage/agency desk.
Futures are transacted on the exchange either using the internal exchange representative or a broker
on the exchange. The London traders conduct their trading activity in much the same way before they
transfer their information to the NY Trading Assistants and leave for the day at 12:30 P.M. New York
time.
For the Trading Assistant, end of day in London means that all activity transacted by the departing
traders must be reconciled (most likely against their trading blotters) and with the various
brokers/market makers/sales/exchanges/internal desks used. Once they have been confirmed, the
Trading Assistant books the transacted activities in the internal system.
At 3:00 P.M. the Chicago Board of Trade closes for the day. Trading Assistants must be ready to tie
out the trading books Futures activities with the relevant Futures brokers. They must confirm the
number of contracts transacted throughout the day, the type of contracts transacted, and that the
prices match what the broker has and what they have input into their internal system.
By 5:30 P.M., the end of day procedure begins.
Risks in a Typical Trading Day

The blotter used by the Trading Assistants is what allows them to shadow the traders’ intra-day
activity and to tie out all daily risk and P&L at the end of the day. This blotter represents the middle
piece of the front-to-back daily reconciliation process.
The Trading Assistant’s blotter takes input (electronic or otherwise) from the various systems/feeds
and traders’ blotters and serves as the central point that incorporates all activity transacted on the
trading desk for a given day.
10
Notes:
Hedges transacted (fed into the proprietary system via the trader blotters) and the swaps that are
transacted (the majority of swaps are fed into external vendors such as Calypso via an electronic
ticket generated through the trader blotters) are all recorded on the Trading Assistant’s blotter.
For the Front Office, the Trading Assistant’s blotter represents the desk’s total Risk & PL for swaps
and hedges. For Operations department, the Trading Assistant’s blotter is the tool against which they
reconcile with the front, thus it is the Trading Assistant’s job to make sure all information recorded in
on their blotter is exact.
In summary, OTC Operations reconcile trades booked into the internal systems and external vendors
(Calypso) to the Trading Assistant’s blotter. At end of the day, should the traders not see what they
are expecting for their P&L or should middle office or Back Office not match and tie out against what
the Front expects, then the error/correction filter up to the Trading Assistant’s bookings.
Before trades are fed downstream, the check-out process consists of:
• Confirming the hedges transacted internally with the Trading Assistants across the bank
• Confirming the hedges done on the exchange with the relevant brokers (information that is usually
shouted out through squawk boxes or via Bloomberg)
• Confirming the derivative trades done via the Sales desk with the sales assistants; confirming
non-vanilla derivatives (20% of the trades transacted by the desk are not vanilla but are
amortizations, unwinds and FRAs) with their relevant counterparties
To reduce risk from misbookings and to monitor breaks, the confirmation process across banks has
been partially automated by the various technology systems available in the market.
On the front end, banks have put in place internal automated matching systems to match all
internally-traded hedges as well as external vendors such as Swapswire (an electronic swaps trade
confirmation system primarily used for brokered trades, but also some direct counterparty trades),
Espeed, and BrokerTec (used to check out treasuries done in the market) and Bloomberg (an
industry-wide pricing, data and communications tool) to help match and communicate with sales,
brokers, and direct customers.
From the front end, all of these booking and matching systems help reduce phone confirmations
before the trades are fed into the bank’s official external vendor (such as Calypso). External vendors
are used by the Middle Office to book, price and maintain all OTC derivative trade portfolios and by
the Back Office to manage official confirmation, payments/settlements and position management.
With high volumes being traded, humans fallacies are common and thus at any given time, any of the
above confirmation/reconciliation methods could fail and trades could be uploaded incorrectly, or
correct trades with incorrect prices could filter down to the Back Office. In these situations, the
repercussions for the desk/bank could be immense.
In some cases, incorrect bookings are caught the day of booking when the Trading Assistant reports
the incorrect risk and P&L to the Traders. In other situations, it is the Back Office that alerts the
Trading Assistant when they see breaks occur with the prices coming in at the end of the day from the
reports sent by the exchange or when they see that the treasuries input by other desks do not match.
Breaks caught the same day, although risky for the desk, can be tolerated but on other occasions
breaks could be noticed a day or two later when the Back Office receives settlement confirmations for
treasuries transacted with external counterparties. These breaks could mean serious problems for the
desk.
11
Notes:
Less frequently, only the treasury has been incorrectly booked (the quantity or price is off) but on
most occasions, the external treasury was transacted as part of a swap transaction and there would
probably be a swap that also has to be reversed.
12
Notes:
1.2 Back Office Operational Responsibilities

The Front Office executes trades and (depending on the volume and size of the institution) with the
help of Trading Assistants, the transactions are fed into the downstream system.
The Back Office is responsible for processing, confirming and managing the transactions conducted
by the Front until maturity or more precisely delivery. They are responsible for the actual exchange
(payments made and received by the bank) derived from the executions of the Front Office.
The Back Office employee is usually focused on a certain division of the bank and depending on the
division/product they are assigned to the job responsibility of one Back Office member could greatly
differ from another’s.
In general, the responsibilities of a typical Back Office employee include monitoring and reconciling
the firm’s assets, importing curves and market data, running and reconciling market values,
confirming transactions, generating and importing statements/reports to and from clients, agents and
clearing houses, updating the relevant systems with the relevant reference data and static data such
as product information (i.e., should a treasury roll over and a new one be auctioned, or should a future
roll over and a new one replace it).
Back Office employees also manage the firms balance sheet, managing rate fixings when applicable,
interacting with counterparties / custodians / exchanges and administrators to resolve breaks and
open issues and finally keeping a close connection with the trading desk (via the Trading Assistant or
otherwise) to confirm and avoid any discrepancies.
In order to accomplish this, the Back Office will transact various processes on a daily basis and/or
periodic basis. The processes typically conducted by the Back Office are listed below.
Daily Operations
Start of Day
• Check batch processes – completion
• Distribute reports
• Reconcile
• Review overnight issues
Trade-Specific Processing
• Accept trades
• Confirm financial details
• Confirm generation of flows
• Verify confirmation with counterparty
13
Notes:
• Confirm settlement details
• Pay/receive funds
• Reconcile accounts
• Confirm matching
• Investigate funds not received
Trade Processing in General

• Workflow/Task Management
• Exception Handling
• Process Monitoring
Accounting
• Make account entries
• Adjustments/reversals
Rate Resetting/Price Fixing

• Market Data input/feeds
• Automated or manual capture of quotes/prices
• Input official market data: FX Fixings, IR Resets
Inventory Management
• Cash and Security positions
Margin Call Management

• Each day relevant product is traded
• Fund coverage
14
Notes:
End of Day (EOD)

• Input EOD Curve for Mark-to-Market
• Monitoring of position held and running Mark-to-Market and P&L reports
• Reconcile positions per book/desk
• Send account postings to the main GL system overnight
• Monitor FX – payment deadlines
• Futures/Options – broker statement reconcile (trade checkout)
• Reconcile P&L and positions with Front Office
Periodic Operations
Credit Events (for counterparty & agency ratings)
• Downgrade/upgrade, defaults, bankruptcy
Static Data Maintenance

• Legal Entities
• Settlement Instructions
• Legal Agreements
• Security/Access Restrictions
Monthly/Yearly Official Statements

• Monthly / Yearly account closings
Lifecycle Management
• Corporate Actions (Bonds, Equities)
• Termination (upon agreement with Counterparty)
15
Notes:
• Option Exercise
• Exchange Traded Option Exercise
• Future Expiry (affects positions, P&L, Postings)
• Trade transfer – trades moved between books and Counterparties
• Position Transfer – Transfers an entire position for settled trades
• Rollover (typically for FX, MM, short-term securities into next contract)
With all the above to cover, the Back Office employee must have the tools (capable platform, correct
static data and reference data setups) to efficiently produce the proper documents, payments, and
accounting entries for each type of trade.
16
Notes:
Module 2: Calypso Design
and Architecture
• Describe the Calypso architecture
• Explain how the Persistent Subscriptions model functions in

Calypso
• Describe the Calypso Engines
• Describe the Calypso Applications
• Explain the high-level design of trade management in Calypso
• Describe how a trade is processed in Calypso

MODULE 2 Calypso Design and Architecture
Introduction
This module discusses the Calypso architecture and the Calypso conceptual design model as it
relates to Back Office business and functional requirements.
The various components of the systems architecture (the database layer, the data backbone layer -
Data Server and Event Server- , the Calypso Engines, and the Calypso client applications) will be
discussed.
This module also provides a high-level overview of how products and trades are processed in
Calypso.
18
Notes:
2.1 System Architecture

Calypso (version 13 and under) has four layers; a database layer, a data backbone layer (Data Server
and Event Server), a set of engines, and a set of client applications.
Data Base Layer

The database is used for transaction processing only. Calypso supports Oracle and Sybase.
All data is ultimately stored in a relational database. The data model is logically partitioned so that
data types are separated. In addition to ensuring a clean design, this approach allows customers to
adopt / add different securities and update policies for different types of data.
For example, all of the reference data can come from some external master customer or security
databases. The data model is open and visible using the DB Browser application, but users do not
interact directly with the database.
Data Server Layer

The Data Server is the central point of the architecture where engines and applications obtain
information. It determines which events should be generated when there is a change in the persistent
data.
The Data Server is responsible for:
• All database access
• Workflow implementation
• Applying workflow rules
• Publishing / generating basic business events
The Data Server maintains a cache to improve performance. When the Data Server is started, static
data is loaded into the cache, which continues to build as other Calypso engines and applications
request data. It is possible to initiate startup scripts that help “prime” the cache so that a large
percentage of the cache is automatically loaded just after the Data Server starts.
Data is also cached at the local (application) level. The data server keeps both the local and its cache
current. For better control and ease of administration, the data server’s cache is partitioned according
to the type of data stored (Reference Data, Trade Data, etc.).
Calypso also supports RO (Read Only) Data Servers. Read Only Data Servers provide an alternative
to the primary Data Server and help to reduce the load on the primary Data Server. A Calypso user
can connect to the RO Data Server for batch and data-intensive jobs. The Read Only Data Server
builds a cache as data is requested. It keeps the cache updated by subscribing to events in real time.
Audit/Versioning can also be implemented in the Data Server. When a trade/transfer/message is
saved, the Data Server acknowledges this lifecycle and generates audit/versioning for this first
version. It generates the necessary events and saves them in the database. Thereafter, the Data
Server publishes the events to the Event Server in chronological order.
19
Notes:
In Calypso, it is possible to run two Data Servers simultaneously, with one serving as a hot standby to
the other. In this case, if the main Data Server goes down, the backup cuts in immediately so that
applications continue to work.
Event Server Layer

The Event Server manages event publications from the Data Server and broadcasts events (to
subscribing Engines).
An Event is any external, real-world activity that is handled by the system. Examples of Events
include a saved trade, a liquidation of a position, a rate reset, a trade cancellation, and a partial
termination. When data about one of these activities is saved to the database, the Data Server
generates an event.
Calypso engines and applications subscribe to events using the Calypso Event Server. After the Data
Server publishes an event, the server distributes the event to subscribers. The Event Server ensures
that events are passed to other system components that may be interested in the particular events
using a publish-and-subscribe mechanism.
The method of communication used between the Event Server, Data Server and allows the system
components to cooperate and interact in real-time without directly communicating with each other or
polling the database. This improves both the reliability and performance of the system.
Calypso Event Naming Conventions

When an event occurs, Calypso has a naming convention it uses. The Calypso naming convention
for events is PSEventXXX. PS stands for Publish-Subscribe after the publish-and-subscribe
paradigm. XXX normally represents the particular event name representing / corresponding to the
activity that occurred. For Example, when a Trade is saved in Calypso it would instigate a
PSEventTrade to be published.
In order for the publish-and-subscribe paradigm to work correctly and for institutions to obtain their
required information according to their business needs, the PSEvents that are of interest and need to
be accounted for must be part of the user’s Calypso Event Configuration and the PSEvents published
must coincide with relevant Engines.
20
Notes:
The following table gives an example of some of Calypso’s Back office Published events and the main
corresponding subscribing engines.
Publication Subscription
PSEventTrade Transfer Engine

Message Engine
Accounting Engine
Position Engine
Liquidation Engine
PSEventTransfer Message Engine

Accounting Engine
Inventory Engine
Margin Call Position Engine
PSEventValuation and / or Accounting Engine

PSEventPositionValuation
PSEventRateReset Transfer Engine

Message Engine
Accounting Engine
PSEventUnliquidatedPosition Accounting Engine

PSEventLiquidatedPosition
Transfer Engine
Refer to the Engine section below (reviewing Engine description) to determine the
responsibility and output of the engines listed above.
21
Notes:
Engines
Calypso Engines are responsible for the system business logic.
An Engine in Calypso can be defined as a real-time application, subscribing to certain types of events.
They do not store data but subscribe to and are triggered by certain types of events for which they
carry out the processes requested by the events and publish the processing results.
In other words they enable the system to provide reliable, real-time functions for processing trades.
For example, the Message Engine reacts to Trade Events and produces confirmations based on
these.
All engines use the same process:
1. Subscribe to an event
2. Get the event (e.g., new trade entry)
3. Process the event (e.g., create transfer entry)
4. Save the result to the Data Server
As Engines provide the core business functions of the system, even if only one specific engine is of
interest to users it is essential for Calypso users to have a basic understanding of the internal
mechanism of Engines.
Persistent Subscription
Each Engine subscribes in a persistent way to Events. This means that whatever happens to the
system (general system shutdown, database crashes, engine failure), as long as an Event has not
been fully processed by the required Engine, the Event will remain in the system.
In other words, once an event occurs in the system, subscriptions and event deliveries are all
accomplished regardless if the receiving engines are running or not. Thus there is zero point
business failure.
For example, if a subscribing engine is not running at the time an event is published, it does not
receive events. While it is off-line, the Data Server builds a list of all events that have not been
processed in the database.
When it starts again, the subscribing engine will access the Data Server to determine if there are any
unprocessed events of the type it is interested in. It will begin processing these events and will defer
input from the Event Server until the backlog of persistent events is cleared.
An Event is considered fully processed by an engine only when the following conditions have been
met:
1. All the processing required by the Event has been correctly performed without any errors and is
saved in the database
2. The Event is flagged as processed by the Engine
22
Notes:
If any errors have occurred during processing, the system acts as if “nothing has happened”
leaving the system and the database in the same state as before the processing of the event.
Therefore, it is safe not to have an Engine running all the time. For example, if a Trade is saved and
the Message Engine is not running, no messages will be produced. However, as soon as the
Message Engine is started, all outstanding events are processed and the required messages are
generated (e.g. confirmations, payments etc.).
Another example would be if, during the processing of an event, the Engine has shut down. As the
Event has not been fully processed, the next time the Engine is restarted, the event will be processed.
The Calypso Event Server guarantees delivery of all persistent subscriptions and also guarantees that
each event will be consumed exactly once.
In the publish-and-subscribe communications model, the application that creates an event does not
need to know who will receive the event. Instead, it sends an event message to the event service
stating that an event has occurred, and the event service forwards the event message to every
subscriber that has registered its interest for that type of event.
Subscribers register their interest by subscribing to a given event type. With a subscription in place,
the subscribing application will receive notification each time the specified type of event occurs in any
application on the network.
The Event Server, in conjunction with the Data Server and the Database, guarantees that all
persistent (business) events are delivered and processed. Calypso has a number of Front Office and
Back Office Engines. The engines commonly used by the Back Office (at least at an introductory
level) are listed below.
Transfer Engine: A transfer represents a flow of cash or a security from one organization to another.
Transfers can be generated in response to trades or rate resets.
Message Engine: A message is a generic term for advices, confirms, payment instructions and all
the other documentation needed for trade processing. As trading and processing proceeds, the
Message Engine knows which messages to generate and who to send them to.
Accounting Engine: The Accounting Engine generates general ledger postings in response to
events such as new trades, trade amendments, and position revaluations.
Liquidation Engine: The Liquidation Engine tracks the holdings of each Trading Book. The
Liquidation Engine keeps track of all of the instruments in a Trading Book including OTC instruments,
cash, and securities. Positions are updated in response to trades. New trades can cause old trades to
be liquidated and profit or loss to be realized. Realized and unrealized P&L are updated after each
trade.
Inventory Engine: The Inventory Engine tracks of the amount of a given security or currency that an
organization owns. This inventory is broken down according to the agent (Custodian, NOSTRO, etc.)
that holds it for the organization.
Task Engine: Trades, Messages and Transfers go through a lifecycle that users can configure. Each
step in the lifecycle is a task. The Task Engine generates the tasks that need to be completed at each
stage in the processing lifecycle. If you are setting Workflow Tasks with kick-off timers and cut-off
alerts, you need to run this engine.
Other engines that are relevant to Back Office functions include:
23
Notes:
CRE Engine: Firms that do not use Calypso to generate accounting postings still need to feed their
own general ledgers. The CRE Engine generates a data package whenever an Accounting Event
occurs.
CRE Sender Engine: The CRE Sender Engine is responsible for sending CRE’s to the external
General Leger.
Incoming Message Engine: When a message is received through a gateway from an external
source, the incoming message engine processes that message. This processing generally involves
changing the workflow state of the message in Calypso.
Margin Call Engine: The Margin Call Engine calculates margin amounts based on daily changes in
inventory. Users can plug in their own margin algorithms.
Sender Engine: The Sender Engine is responsible for delivering appropriately formatted messages
to recipients using SWIFT, FpML, FIX.
Billing Engine: Responsible for generating management fees.
Import Message Engine and Matching Engine: Responsible for importing incoming messages and
matching.
Position Engine: The Position Engine calculates settle positions for trades without liquidating them.
Scheduling Engine: Certain activities such as producing reports or maturing trades are done at
regular intervals. The Scheduling Engine ensures that Scheduled Tasks are performed on time.
Engines can be added or extended as required. The same engine can also be set up to run on
more than one machine. Calypso also allows adding custom engines.
Subscription and Filters

Persistent subscription must be set up in Calypso. The setup for each Engine is done and can be
viewed from the Event Config Window. This is accessed via:
Main Entry > Configuration > System > Event
24
Notes:
Calypso provides a standard set-up for all Calypso Engines. If new Events are added or new
Engines that need to subscribe to particular events, then the Event configuration setup will need to be
modified in order to reflect the new addition.
Each Engine can subscribe to one or more types of events. Event traffic in Calypso is optimized to
reduce network traffic.
Depending on the event, it may or may not be necessary to retrieve the event data from the Calypso
Data Server. To control information received, when declaring a persistent subscription it is possible to
use Event Filters to avoid unnecessary events being sent.
25
Notes:
For example, the Transfer Engine uses a “VerifiedEventFilter”: the purpose of it is to filter all the
Trade Events, which are not in a Verified or equivalent status. Therefore, “Pending Trade” or “Pricing
Trade” will not trigger the processing of the Transfer Engine.
Applications
The term ‘Application’ in Calypso applies to the available platforms that allow users to perform a
number of actions. They are responsible for converting JAVA objects into graphical elements.
Applications present information to users and take user input. Some have no engine interaction and
no business logic while others have. Calypso has numerous applications. For Back Office purposes,
some of the most common applications include:
• Applications allowing management of event life cycles. For example, exercise/termination/rate and
reset/rate fixing
• Applications related to exception handling/verification/modification. For example, Task

Station/Trade Window
• Applications related to the presentation of information. For example, Message Reports, Transfer
Reports, Accounting Reports, Balance Reports, Liquidation Reports and Audit Reports
• Applications related to position management. For example, Back Office Inventory, Portfolio
Manager, and the Collateral Manager
26
Notes:
Certain applications (including Engines) can publish and subscribe to events. For example, the Trade
Window, an application for capturing trades will ‘publish’ PSEventTrade, which the Transfer Engine,
Message Engine, Accounting Engine and Liquidation Engine can subscribe to.
For real-time reporting purposes, some reports also subscribe to events published by engines
such as PSEventPLPosition and PSEventInventoryCashPosition.
Reports should have the real-time- check box flagged. The subscription of reports to specific PSEvents is
hardcoded. If real-time is not checked, to obtain updated data/information, users will need to apply the
‘Load’ button on each report. Users should check the ‘real-time’ checkbox with careful consideration of
their volumes
Utilities
Trading
Static
Data
Trade
Reporting Lifecycle
Market Data
27
Notes:
Overall Process Flow

Having defined the main layers of Calypso’s architecture, using an example of a trade being saved –
thus PSEventTrade being published - we can break down and review the process flow the system
goes through.
1. The trading application sends the trade to the Data Server
2. The Data Server saves the trade and a Trade Event to the database as part of the same database
transaction
3. If the database transaction is successful, it publishes the new event to the Event Server
4. The Event Server consults the list of subscribers to trade events and sends the event to each
subscriber
5. Upon receiving the event, each subscriber loads the necessary data needed to process the event
6. After processing the event, each engine saves the results along with an acknowledgement to the Data
Server
7. The Data Server saves the results to the database, and marks the event as processed in the database,
in a single transaction
The diagram below shows the process:
Applications
Engines
Data
Transfer trade event 1 Backbone trade event 1 Blotter
sd event
Message Event
Server
trade event 1 Save static data Other App
Accounting
Data
acknowledge Server
Inventory d
trade event 1
Liquidation Trading
Save trade # 123 App
Database
Task
28
Notes:
The same process flow as above is used for every one of the below listed events and engine
subscription relationships to provide Back office related outputs.
PSEventTrade Transfer Engine – When a trade is saved and/or amended,

some form of cash and/or security will be exchanged. In
Calypso, ‘Transfers’ need to be created to represent this.
Message Engine – When a trade is saved and/or amended,
some form of verification/confirmation of the trade will need to
be exchanged with the counterparty. In Calypso, ‘Messages’
must be created.
Accounting Engine – When a trade is saved and/or amended,
some form of accounting for the transaction that took place will
need to be registered. In Calypso, ‘Accounting Entries’ need to
be created.
Liquidation Engine – When a trade is saved, dependent on
the product traded, there would need to be an update on the
held instruments, e.g. ‘Liquidated/Unliquidated.’
PSEventTransfer Message Engine – When there is an ‘actual’ movement of

cash/securities due to the transfer/exchange, the financial
institution would most likely need to generate ‘messages’ to
verify/confirm actual movements.
Accounting Engine – When there is an ‘actual’ movement of
cash/securities due to the transfer exchange account for these
movements in their books and records via ‘Accounting Entries.’
Inventory Engine – When a transfer is saved and/or updated,
Treasury positions would need to be updated.
Margin Call Engine – Treasury positions held could also be the
catalyst for margin calls.
PSEventValuation Accounting Engine – It is assumed that Back Office users

need to run valuation (MTM, Accrual, etc.) on transactions
PSEventPositionValuation
and/or on positions held.
PSEventRateReset Transfer Engine – When there is a rate reset, the Cashflows

associated will need to be updated.
Message Engine – When there is a rate reset,
verification/confirmation messages would/could need to be sent
to the counterparty.
Accounting Engine – When there is a rate reset, accounting
records would/could also need an update to reflect the reset.
29
Notes:
PSEventLiquidationPosition Accounting Engine/Transfer Engine – If the transaction

involves positions held on a particular instrument, most likely
PSEventLiquidationPosition
the Back Office would need to record accounting and the
inventory movements generated from the performance/realized
P&L accrued by the transaction.
30
Notes:
2.2 The Calypso Conceptual Model

Now that we have reviewed the building blocks of the Calypso platform, we can begin to expand our
overall Calypso knowledge by reviewing the default method in which financial instruments and
activities are addressed.
Calypso separates design modeling for Trades and Products. This allows Calypso to easily support
both single and multiple traded instruments and allows reporting and position keeping flexibility.
Product
A Product is a financial instrument that can be held or traded including instruments such as bonds,
future contracts, and stocks. These are often referred to by Calypso users as ‘Position Based’
products.
A product can also be part of a one-off deal that are structured to meet client requirements and traded
only once, like an IR swap or cap. A product can be traded multiple times but needs to only be
defined once. Product holdings often need to be managed independently from Trades.
Trade
A Trade is a financial transaction between two parties, the bank (your Organization) and a
counterparty.
In Calypso, the counterparty is represented by a Legal Entity defined with the role of Counterparty.
The party representing the bank (your Organization) is the ‘Processing Organization’ that owns the
Book in which the trade is made. A trade always belongs to only one Trading Book and a trade is
always a transaction of only one financial product.
Legal Entity Book Hierarchy

Product
Of owns
Within
Trade Book
Accounting Book
It is important to understand these two concepts in Calypso as they determine the ways in which the
system handles/manages financial transactions/activities.
31
Notes:
For example, let’s assume that on 18st Feb 2013, Trader John Doe working on the Treasury desk at
Bank A sold 30mill 10yr USD treasury notes at a price of 100.965.
Using the concept of separation of design, this transaction in Calypso will mean two things. The table
below shows how information is segregated in Calypso.
Trade Product
Trade Id (this would be the system Bond Product id (this would be the
generated number) system generated number)
Concerned Parties (Bank A/Counterparty Name: UST 10yr

A) Bond Type: UST 10yr Feb ’23 2.0 %
Trade Date = 18th Feb 2013 Issue Date: 15th Feb 2013
Quantity (buy/sell) = - 30mill Issuer: US Treasury
Price = 100.965 Maturity Date: 15th Feb 2023
Currency = USD Coupon Rate: 2.0
Trader Name = John Doe Coupon Frequency: S/A
Face Value: US$ 1000
Maturity Tenor: 10 year
With this design, for trades, Calypso maintains a single data model table (in the database) and a
single Class (a single code for all trades).
On the other hand, for each Product (bond/asset swap/equity), Calypso maintains multiple product
tables in the data model (database) per product and for each of these Products, a specific class (code
per product) pertaining to that product. This allows Calypso to address the specific
functionalities/lifecycle events associated with each financial instrument.
We will discuss this concept further and how it pertains to Back Office functionality in the following
sections of this course.
For detailed explanation on Calypso Architecture and design, refer to Calypso Documentation.
32
Notes:
Module 3: Access, Static Data
and Reference Data

• Understand the business requirements behind Access Permissions
• Understand how Access Permissions work in Calypso
• Understand the use of Legal Entities
• Understand relevant roles of Legal Entities
• Define Legal Entity Contacts
• Describe how Legal Agreements are used
• Define Trading Books and Accounting Books

MODULE 3 Access, Static and Reference Data
Introduction
In Calypso, you are set up as a user, given a password, and are recognized by the system as part of
a particular group (for example, the department that you are working with). As such, you are given
certain permissions and rights. In Calypso, these permissions and rights are granted using Access
Permissions.
Once Access Permissions have been defined Static Data and Reference Data should be in place in
order to allow users (you) to conduct their (your) daily duties.
This module discusses some of the types of set ups required for several users in different
departments.
34
Notes:
3.1 Access Permissions

A financial institution, or any given company for that matter, usually has several forms of security
checks and controls to make sure that no real pertinent transaction/activity (and in the case of a bank,
no real exchange of cash/security) transpires before the act is authorized in one form or another. The
security checks implemented by a company are largely at their discretion.
The checks put in place when a particular action (resulting from an internal or external transaction)
transpires can come in several forms. For example, a user can input a transaction into the system and
the action can be approved by a different user with different approval rights or, a user can input a
transaction into the system but the transaction could have several parts that require the information to
be cross-checked by several departments before being approved.
Companies require a fairly strict level of security to ensure that transactions do not break
laws/jurisdictions, expose the company to market/credit risks, payments are not made for the wrong
amounts and worse, to the wrong recipient and sensitive reports are not accessible to the wrong
people. In short, companies control who and when employees can transact actions so that the wrong
information does not fall into the wrong hands and they do not risk any loss or embezzlement issues.
Calypso provides several ways to implement controls. One is using the Access Permission
functionality and the other, often used by Back Office teams, is via the Workflow and the four-eyes
principle. (We will review the four-eyes principle in the Workflow and Task Station sections of this
course).
The Access Permission functionality in Calypso allows an organization to define and manage the
access permission of individual users (which are recognized to be part of a defined group) and also
determine what authorization capabilities these users within the group have.
The list and combination of Access Permissions available within Calypso are extremely rich, covering
subjects that range from: system behavior, Calypso applications, market data, back office processing
for transfers / messages / postings, back office lifecycle (Workflow) processing, Back Office use of
Task Station, trading capabilities, product permissions, reference data, and reporting.
Using the Access Permission functionality, the system allows you to define which users (within a
group) are allowed to have access to a particular Trading Book, product, who has rights to save
counterparty information, who can save a trade, and price a trade.
For pricing, you can define who has access to Pricers/curves, who performs actions on the trade (i.e.,
modify trade), who reviews/modifies and has access to functions for Back Office trade processing.
(Transfers / messages or posting), who manages the trades lifecycle – workflow - thus possibly
cancel’s the trade, and who can access trades information in reports.
Eventually, you will also define which of these permissions must be authorized and who will be the
authorizer.
Configuring Users and Groups

For our purpose, as an example, we have set up a few users/groups to show you how the logic can
work. The table below shows you that we have defined several users, put these users in groups, and
defined passwords for them.
35
Notes:
Users Group Password
Trader x cm_trader Calypso
Ta/middle office user 1 Ta/Middle Office Calypso
Calypso_bo_accounting accounting Calypso

user 1
Calypso_bo_operations Operational Calypso

user 1
Calypso_bo_operations Operational Calypso

user 2
Calypso_bo_eod_user 1 Eod risk Calypso
Calypso_bo_management_ Ops management calypso

user 1 Accounting eod risk
operational
Configuring Groups
As these users have been setup for example purposes, please note that in reality it is unlikely that
their passwords would all be the same.
Calypso defines Access Permission for users by Group. You will define Groups under the ‘Group’ tab.
There are six types of groups listed in the table above. We will be using some of the groups as
examples throughout this course.
To configure user/group access permissions navigate to:
Main Entry > Access Control > Access Permission
Assuming you would you had to define a specific group for Traders for example, you would follow
similar steps as our below example for cm_trader group.
36
Notes:
Define the Group cm_trader.

In our case, this group is set up for the user ‘trader x.’ He/She will represent a Capital Markets Trader
and will only have a role of inputting, pricing and modifying trades.
2
1
1. Select the ‘New’ button under the Groups Tab. This will clear the window
2. Click the ‘Save as New’ button to define a name for your group
3. When the ‘Save As’ window displays, define the group’s name using the free format field and click
‘OK’
For our above group case, we have defined cm_trader
4. Once saved, the name of your group will display in the top ‘Name’ field
37
Notes:
In the event you need to edit the group, use the ‘Edit Group’ drop-down to select your group,
edit as necessary (add comment/reference user/filter set etc.), and click the ‘Save’ button.
In the event you need to remove a group, use the, use the ‘Edit Group’ drop-down to select your group
and click the ‘Remove’ button before selecting ‘Save’ button.
Using the same steps as described above, we have set up the following groups.
Group: ta/middle office

This group has been set up for the user ta/middle office user 1. This user has a Trading
Assistant/Middle Office role where they are responsible for confirming the trades (internal or external)
transacted by traders with traders/brokers/sales and/or exchange and after doing so, ‘officially’
confirm the trade by saving it into the system. In addition, in scenarios where trades are incorrectly
input or missing information, we would also consider them as someone who can modify trades. This
includes adjusting information or adding new information to trades (counterparty/trade
quantity/price/broker amounts etc.).
We have also set up the following groups:
Group: accounting / operational / eod risk

These three groups will be set up to accommodate three functionalities. In general, the three groups,
as a whole, represent ‘Back Office’ operations. Better put, in a financial organization the job
functionalities of the three different groups is considered part of Back Office Operations department.
However, dependent on the size of the company, these groups could be split into their distinct
departments within ‘Back Office’ operations or, in the smaller houses, less distinct roles.
In this case, we have defined separate groups against which we have added different users for
visibility. Here we have split general ‘operational’ processing between three groups. One operational
group is for general Back Office functionality (cash/security payment and receipt management,
message management, position management, lifecycle management, and reporting). One group is for
End-of-Day Risk (Eod risk group) for saving official EOD marks / curves. The third group, the
Accounting Group, is assumed to manage the bank’s chart of accounts.
These three groups have been assigned to the following users:
• calypso_bo operations users 1 and 2
• calypso_bo_accounting user 1
• calypso_bo eod marks user 1
Group: ops Management

This group has been setup to represent for example, the Authorizing Group for the users in the three
groups above. As a result, the Access Permissions permitted for this group would be greater than the
38
Notes:
accounting/operational and eod risk groups. The functionality for this group is to handle approvals and
also serve as task executors.
Defining Users
The individuals defined in the ‘Users’ tab represent those people who will be using the system. Each
individual using Calypso, must have a user name. This name (the User Login) is required by Calypso
when the Main Entry launches.
All users will be associated with one or more groups. To define users, follow the steps below;
2
5
6
1
1. Select the ‘New’ button to define the user details

2. Using the ‘Full Name’ free format field, define the name of the user
You can use the ‘Description’ field to input any information that could be useful. The description
field does not have any system impact and is a free format field
3. Click on the ‘Select Group’ ellipsis to open window to allow you to associate the user you are
defining with a particular group or groups
39
Notes:
In our case,
we have
defined the
calypso_bo
management
user 1 to
belong both to
his own ops
management
group and also
to have access
to the
permissions of
the listed
three groups.
4. In the ‘Password’ field, define a password for the user you are configuring
You will need to retain this password as it is used when you login into calypso using the Main Entry.
5. Should you require that the user being configured can only have access to a specific Processing
Organization, then using the ‘Processing Organization’ ellipsis, designate the PO desired for the
user
6. When ready, select the ‘Save’ button. The system will prompt you to input the required User name
in a pop-up window
Input desired name

for user (example:
trader x) and select
OK.
6
40
Notes:
Once you have clicked the ‘Save’ button, the system will add your saved user name to the
‘User Name’ field and will also include it as an option to select using the drop down, via the ‘Select User’
dropdown.
For this class, as per the original table shown above, using the same steps as above, we have
defined the following users in our system:
• trader x
• ta/middle office user 1
• calypso_bo_accounting user1
• calypso_bo operations user 1
• calypso_bo operations user 2
• calypso_bo eod marks user 1
• calypso_bo management user 1
Once you have defined your user, you can the user can determine his/her preferences via:
Main Entry > Configuration > User Access Control > User Defaults.
Defining Access Permissions

Defining Group Access Permissions
41
Notes:
Selecting one of
the subjects on
the branch (of the
tree to the right)
activates one or
all of these
buttons by which
users can
determine the
permissions
/authorizations
desired.
For each of the headings in the tree branch ‘Access’, to refine the access permissions of the group,
users will need to highlight the relevant heading and use the Read/Write or Read Only windows.
A selection window with filter capabilities will open for each heading, allowing you to select (from a list
relevant to the heading in question) the access right desired.
When the ‘Add Read/Write’ button is activated for the selected heading, users can determine what
access /authorization the group has and the accesses chosen give rights to users in the group to both
view (thus read) and be able to determine the level of changes (thus write), create/modify etc. to the
particular subject.
An example; when the heading ‘Book’ from the tree branch is highlighted and the Read/Write button
selected, the system will open a selection window showing you all the Trading books within the
system and from them you can select the ones you would like your group to have access to, and
dependent on what has been configured against the functions heading, have possibilities to modify.
Thus, the filter selection window will present you with information relevant and dependent to the
subject at hand.
When the ‘Add Read Only’ button is activated for the selected heading, users can determine which
functionalities they have access to view (thus read) but not make changes. Having a read-only access
indicates for the most part, the user has access to view, have access to the source information but
cannot modify or remove.
From the range of headings for which users can have ‘Read/Write’ and/or ‘Read Only’ access
permissions, we will be discussing only the headings that we will be setting up for our group
examples.
The following table lists the types of access and their use.
42
Notes:
Access Type Use
Functions Defines what exactly can be done i.e., the access

rights (add/modify/remove) and authorisation for
the main functions of the system.
These are not limited to, but include, the access
rights for the subjects listed in the ‘Access’ tree
branch list.
Books The group must be granted read-only or read-

write access to individual books.
The books listed here will have the access /
authorization rights determined based on what
has been identified as part of the read/write
within the ‘Functions’ access.
Book Attributes If there are any attributes on the book then the
users in the group must be granted read-only or
read-write access to individual book attributes
Pricing Env In order to create/modify/remove market data

configuration, users in group must have access
to individual pricing environments.
Pricing Config In order to create/modify/remove market data

configuration, users in group must determine the
Pricing Config to which they have access.
Pricing Param In order to create/modify/remove market data

configuration, users in-group must have access
to specific pricing parameters.
Trade Filter To create/modify/remove trade filters, users in-

group must be granted read-only or read-write
access to individual trade Filters.
Static Data Filter In order to create/modify/remove static data filter,

the user must be granted read-only or read-write
access to individual Static Data Filters
Quote Set In order to create/modify and remove market

quotes (CLOSE/LAST/OPEN) the user must be
granted read-only or read-write access to
individual quote types.
Scheduled Task To modify/execute Scheduled Task

configurations the user in the group must be
granted read-only or read-write access to
individual Scheduled Tasks.
43
Notes:
Access Type Use
Application Name In order to run an engine/admin and Main Entry,

the user must be granted read-write access to
the relevant engines and the admin and Main
Entry.
Report Templates For public report templates (which can be used

by any user) user must be granted read-only or
read-write access to individual report templates.
Market Data Types This refers to curves/surfaces.

Within the ‘Functions’ Access read/write we can
define for a user group to create/modify and or
remove market data or market data specifics/
instances of curves like OPEN/CLOSE/LAST.
Market data (curves/surfaces) can belong or not
to a particular pricer configuration.
- If Market data (curves/surfaces) does not
belong to a pricer configuration the user must
individually pick the curve/surface in this section.
- If the Market data belongs to a Pricer
configuration, the user must be granted read-only
or read-write access to the Pricer configurations
that contain the market data under Access >
Pricer Config.
Product Types To input any trade, regardless if the Functions

Access has ‘CreateTrade’ as part of the
Read/Write functionality; users must be granted
read-write access to individual product types as
applicable.
Feed Config If there are market feeds that are required, the
user must be granted read-only or read-write
access to individual feed address mapping
configurations here.
Remaining relevant to the functionalities of our example groups, the headings mentioned in the table
above have been configured with access rights for our six groups (cm_trader, ta/middle office,
accounting, eod risk, operational and ops management).
The below brief review of our access setup for our groups can walk you through on how to define
access permissions:
Group: Operational
Using the ‘Group Name’ drop-down, we selected group ‘Operational.’
44
Notes:
Under ‘Access,’ we highlighted the Functions heading and opened the access selection window by
clicking on the Add Read/Write button.
Using the Permissions section,

we defined the group’s access
rights by selecting the
desired/applicable permissions
and moving them from left
window to the right window.
Use the top arrows to move
permissions from right to left.
The Restrictions section, allows
you to define the restrictions to
be applied on the group. Use
the bottom arrows to move
restriction from right to left.
Apply the ‘OK’ button when
done.
At this stage, for our user groups, we will not be reviewing the full list of access read/write permissions
and their meanings (some will be covered during the class) however, to give course participants an
idea, below is a small example of some of the types of ‘Functions’ that were selected for the
‘operational’ group. The ‘Functions’ chosen correspond to a back office users duties we expect
him/her to conduct.
• CreateBook
• CreateDocument
• CreateFXRateDef
• CreateLegalEntity
• CreateLEContact
• CreateLEMessageConfig
45
Notes:
• CreateLEProcessingOrgSDI
• CreateLESDI
• CreateProduct
• CreateRateResets
• CreateReferenceData
• CreateSpecificResets
The full list ranges from creation type of responsibilities to modification and annulation responsibilities
of trades, transfers, messages, postings, reports, templates, and workflow and Task Station.
Once satisfied with the list of access rights configured for the ‘Functions’ heading, users can select
the button ‘OK.’ The selection window will close and the ‘Functions’ heading under a folder in the tree
will contain the total list of access rights configured.
46
Notes:
Following the same process, we configured and defined the rest of the headings mentioned in the
table for our ‘operational’ group.
47
Notes:
Books: The user Calypso_bo operations user 1 & 2 in the ‘operational’ group can manage data for all
trading books and (as a specific Processing Organization has not been defined as part of the
user setup via the Users tab panel) across all Processing Organizations.
Trade Filter/Static Data Filter: The user Calypso_bo operations user 1 & 2 in the ‘operational’ group
will be using Trade Filters and Static Data filters in the system to transact various back office
related processes. The range of activities and processes that use trade filters and static data
filters in Calypso is quite vast. For example; they are used in reports, accounting rules,
Scheduled Tasks, Message configurations, Settlement Delivery Instruction, Fee generation
process, workflow process etc.
Scheduled Task: The user Calypso_bo operations user 1 & 2 in the ‘operational’ group has the
possibility to work on any of Calypso’s batch End-of-day Scheduled Tasks processes.
Application Name: As the user Calypso_bo operations user 1 & 2 in the ‘operational’ group will be
generating most of the back office relevant operations, in addition to the Main Entry and
Admin Monitor, the user has been given access to the Engines that will be required to
generate the required back office outputs.
Product Templates/Report Templates: User Calypso_bo operations user 1 & 2 has the possibility
to work on all Product Templates and Public Templates.
Product Types: As the user Calypso_bo operations user 1 & 2 has access to work across all
Processing Organizations, the product types has been set to all as we assume the user will
be dealing with various products across different PO’s and Trading Books.
For the system to save the group access configuration, the ‘Save’ button needs to be selected.
48
Notes:
For the steps listed above, the level of manipulation (creation/modification/removal) is managed
using the ‘Function’ Access Permission.
Now that you have seen the way a particular Group Access is setup, you can understand the other
group accesses for the remaining five user groups are setup using the same steps. The only
difference between these is the choice of headings (under the Access tree) defined for each group
and the access rights chosen within those headings.
Below we will review briefly each group’s headings and the rights selected.
Group: Accounting
For the ‘Accounting’ Group, using the Functions heading > Add Read/Write button, the relevant
access rights typical for ‘our’ accounting department user have been defined.
49
Notes:
Most of the rights defined are in relation to creating / modifying / closing accounts as well as to the
generation of accounting entries. Full list of rights defined are included in the spreadsheet provided to
you as part of this class.
Before saving the Accounting group access, we have defined the rest of the headings for our
‘accounting’ group (using the Add Read/Write button) as per the below screenshot before finally
saving configuration.
Books: The user calypso_bo_accounting user 1 in the ‘accounting’ group can manage accounting
data for all trading books and (as a specific Processing Organization has not been defined as
part of the user setup via the Users tab panel -) across all Processing Organizations.
50
Notes:
Trade Filter/Static Data Filter: The user calypso_bo_accounting user 1 in the ‘accounting’ group will
be using Trade Filters and Static Data filters in the system to transact some accounting
related processes. For example; they could require Trade Filters on accounting related
reports and static data’s on accounting rules.
Application Name: As the user calypso_bo_accounting user 1 in the ‘accounting’ group will be
generating accounting entries, in addition to the Main Entry and Admin Monitor, the user has
been given access to the Accounting and Cre Engines that will be required to generate the
required back office entries.
Report Templates: User calypso_bo_accounting user 1 in the ‘accounting’ group has the possibility
to work on all Product Templates and Public Templates.
Group: eod risk
For the ‘eod risk’ group, the relevant access rights typical for ‘our’ sense of an EOD Risk/Market Data
department have been configured. This is assuming that the user’s job functionality within the group is
mainly to save the required EOD quotes/rates & curves.
As seen below, most of the rights defined for this group are in relation to creating / modifying etc.
curves/rates/marks and quotes.
As we did with the groups above, before applying the ‘Save’ button at the bottom of the Group Access
panel, we defined the access rights for the following headings relevant for our ‘eod risk’ group.
51
Notes:
Books: The calypso_bo eod marks user 3 in the ‘eod risk’ group has been setup to manage data for
all trading books across all Processing Organzations.
Pricing Env/Pricer Config/Pricing_Parameter: The user in this group has access only to the
‘default’ Pricing Market Data configuration, thus will be using this Data for the EOD of all
Processing Organizations.
Quotes: The user in this group has access to ‘default’ Market Data Quote type. This too will be used
for all books across all Processing Organizations.
Application Name: The user in this group will not need any engines but will need to have access to
the Main Entry and Admin Monitor.
Market Data Types: As the responsibility of the eod risk group is to save market date, from within the
‘default’ Market Data configuration, these are the list of market data’s on which calypso_bo
eod marks user 3 is restricted to.
Report Templates: calypso_bo eod marks user 3 in the ‘eod risk’ group has access to all public
reports.
Feed Config: Although this functionality is mostly done by front office users/traders, we have given
‘eod risk’ group access also, in the event that they need to obtain live information for cross
checking purposes etc.
52
Notes:
Group: cm_trader
For the ‘cm_trader,’ using the Functions heading > Add Read/Write button, the relevant access rights
typical for a trader requiring to input and price trades has been defined.
Here is the list of headings and their relevant filtered definitions that we defined for our trader group,
before applying the ‘Save’ button.
53
Notes:
For the cm_trader, we have defined both ‘Read/Write’ permissions, and also ‘Read Only’ permissions.
The reason for this is because, the users in this group, being traders, will be saving and pricing
trades.
As part of the ‘Functionality’ access permission defined for cm_trader group, one of the permissions
defined is to be able to save trades but not create/modify or remove Pricing Environments/Market
data/quotes etc. This access was given to the group eod risk. Thus, in order for the trader who is not
in the same group as eod risk to be able to price trades, they need a way to obtain data.
The way they can have access to this data, without being responsible for creating/modifying or
removing the data, or without influencing the date in the system, is by just having the Read Only
access for these features.
Books: In the Users panel, we had defined that user ‘trader x’ was limited to Processing Org CUB,
thus in this case, the fact that we have defined ‘Any’, means that this trader has access only
to books limited to Processing Org CUB.
Pricing Env/Pricer Config/Pricing_Parameter: We do not want the traders to input (create/modify,
etc.) curves, quotes, etc., but we do want them to need to be able to use the curves input into
the system by the eod market risk team. Thus we have given them the right to view the
Pricing Market Data configuration within ‘default’.
Trade Filter: Traders in cm_group could require the possibility to use Trade filters in some trade
reports thus they have been access to use them.
Quotes: Same in point ii above, we have given the traders in this cm_trader group access to view
and obtain the ‘default’ Market Data Quote type.
Application Name: The users in this group will not need any engines to input trades but will need to
have access to the Main Entry and Admin Monitor.
Market Data Types: From the ‘default’ Market Data Configuration, the traders in cm_trader group
have been given access to view and obtain only the listed curves.
54
Notes:
Report Templates: As traders may also want to save their own templates, the group cm_trader has
been given access to all public reports.
Product Types: cm_trader group has been given access to trade Equity and Swaps. This means,
in our case, ‘trader x’ can trade only for Processing Org CUB using any trading books, but is
limited to these two products.
Feed Config: Traders use live feeds to price their trade’s thus need constant and latest information
on the latest market movement (bid/ask/mid, etc.) of prices throughout the day. They acquire
this by having access to live non-stop feeds (such as Reuters) that are fed into their pricing
modules/sheets.
For all of these listed headings, for the cm_trader group, we have implemented some restrictions via
the ‘Functions’ heading. These restriction are: ‘
• Disallow Save Quotes From Curve = Restriction to disable the Save Quotes button in the Quotes
panel of the Curve windows
• ModifyOnlyProcessingOrgTrade = Restriction to amend only trades that are in the users specified
Processing Org (defined in ‘Users’ tab)
• ViewOnlyProcessingOrgTrade = Restriction to only view the trades associated with the users
Processing Organisation
Group: ta/middle office
For the ‘ta_middle office,’ using the Functions heading > Add Read/Write button, the relevant access
rights typical for a trader’s assistant (ta) role has been defined.
55
Notes:
Here is the list of headings and their relevant filtered definitions we defined for our ta/middle office
group, before applying the ‘Save’ button.
56
Notes:
The ta/middle office users in the ta/middle office group have access similar to the cm_trader, where
we have defined both ‘Read/Write’ permissions, and also ‘Read Only’ permissions and we have also
added additional permissions for them, to allow them to work and monitor trades and their lifecycle
using the Calypso Task Station.
The read/write permissions, like the traders, allow them to save/modify/price trades and this is
because the users in this group, taking particularly trading assistance as an example, do often save
the trader executed trades once they have done the initial confirmations necessary with either the
counterparty involved, the brokers/sales/exchanges.
As explained, they are often the first form of confirmation with the counterparties or facing party
before the trades are input pushed down the system for Back Office operations to begin the real back
office process related to the transactions.
Depending on the volume of the transactions on a particular trading desk, part of the confirmation
process of a TA’s functionality could also be to price trades and check/confirm amounts determined
for hedging with the brokers etc. Thus, as the cm_trader group, they have been given access to view
the same Market Data information without being involved in the creation of the data.
Books: As often TA’s work for a particular desk/department, their book and processing organization
configuration is like the cm_trader group configuration. They can work on any Trading Book
which belongs to their Processing Organization CUB.
57
Notes:
Pricing Env/Pricer Config/Pricing_Parameter: ta/middle office group will not be inputting

(create/modify, etc.) curves, quotes, etc. but as they will view prices on trades they have been
given the right to view the Pricing Market Data configuration within ‘default’.
Trade Filter: TA’s in the ta/middle office group will be using several reports thus will require the
possibility to view those accessible for them.
Quote Set: Same in point ii above, we have given the ta/middle office users access to view and
obtain the ‘default’ Market Data Quote set.
Application Name: The users in this group will not need any engines to input trades but will need to
have access to the Main Entry and Admin Monitor.
Market Data Types: From the ‘default’ Market Data Configuration, the ta/middle office user has the
same access as the cm_trader, which is to view and obtain only the listed curves.
Report Templates: The ta/middle office will want/need to save their own templates, the group has
thus been given access to all public reports.
Product Types: Like the cm_trader group, the ta/middle office group has been given access to
trade types Equity and Swap. This means, users can only work on Equity or Swap trades
done by Processing Org CUB, using any trading books.
Feed Config: To double check prices used to price trades, TA’s will need access to live feeds.
For all of these listed in the above points, the level of manipulation (creation/modification/removal) is
managed via the ‘Function’ access permission. For this user, these restrictions (some similar to the
cm_trader and others for specific ta/middle office functionalities have been applied).
• Disallow Save Quotes From Curve = Restriction to disable the Save Quotes button in the Quotes
panel of the Curve windows
• ModifyOnlyProcessingOrgTrade = Restriction to amend only trades that are in the users specified
Processing Org (defined in ‘Users’ tab)
• ViewOnlyProcessingOrgTrade = Restriction to only view the trades associated with the users
Processing Organisation
• ViewOnlygroupTaskStaion = As user has permission to ViewOtherTaskStation (in the Task

Station), we have restricted them to view only the tasks of users in the same group
• ViewOnlyProcessingOrgStaticData = Restriction to only view the accounts/message

configurations/trading books associated with the processing org of the user currently connected
58
Notes:
Group: ops/management
For the ‘ops management’ group, using the Functions heading > Add Read/Write button, the relevant
access rights typical for management have been defined.
Here is the list of headings and their relevant filtered definitions we defined for our ops management
group, before applying the ‘Save’ button at the bottom of the Group Access window.
59
Notes:
The functionalities defined for group ops management are in relation to authorization. If we take our
user calypso_bo management user 1 (who is a member of this group), we can see that his role has a
two-fold functionality. This means, as a user within this group, he/she has a ‘management’ sort of role
where he/she can authorize the activities of users of other groups and at the same time, he/she can;
conduct certain functionalities outside of authorization. This is due to the ‘Users’ access we gave
calypso_bo management user 1.
By defining the groups to which the calypso_bo management user 1 belongs to (as per the above
screenshot) we are in fact telling the system that this user, has access rights to the ops management
group’s access rights defined in the ‘Group Access’ tab (which is mainly management authorization
functionalities) but also will be able to conduct/have the rights of the other groups; accounting group,
eod risk group and operational group.
60
Notes:
This user thus, is configured much like master user that has functional and managerial possibilities.
Books: Users in the ‘ops management’ group have access to all books across all PO’s.
Pricing Env/Pricer Config/Pricing_Parameter: Users in the ‘ops management’ group have access
and can authorize all the Market Data configurations available in the system.
Trade Filter/Static Data Filter: Users in the ‘ops management’ group have access to authorize all
the Trade Filters/Static Data Filters available in the system.
Quote Set: Same in point ii above, we have given the ‘ops management’ users access to view and
obtain all Market Data Quote sets.
Scheduled Tasks: calypso_bo management user 1 in the ‘ops management’ group have access to
authorize all EOD Scheduled Tasks run by users in the Operational group.
Application Name: Users in the ‘ops management’ group have been given access to use all
Engines.
Market Data Types: calypso_bo management user 1 access to all Market Data types within the
Market Data configuration list of ii (which is ‘All’).
Product & Report Templates: calypso_bo management user 1 have access to his/her product and
report templates as well as other users in the other groups.
Product Types: calypso_bo management user can view and have access to all product types.
Trading Book Rights

All books require definition of the currencies, currency pairs and products that can be traded in those
books.
Even if under the ‘Book’ heading of the Group Access panel (for a given group) ‘All’ was defined,
when setting up access rights, users will still need to define a currency, currency pair and product
configuration for each book that will be used.
61
Notes:
The permission defined within this panel defines the access rights of specific Trading Books and is
regardless of a particular user or group. For every Trading book, Calypso requires specification on
which currencies, currency pairs and products can be traded in that book.
Once the book checkbox has been checked, select a Trading Book using the drop down arrow. In our
example, we have selected Trading Book ‘Equity Trading Book.’
Check the ‘Book Attr’ button if you desire to specify the attributes the Trading Book has rights to use.
Using the ellipses buttons next to Currency, Curr.Pair and Product, you can select the relevant
currency/currency pair and product to be traded by a particular book.
For our Equity Trading book, we have defined;
• Currency = EUR & USD
• Currency pair = All
• Product = Equity
For our OTC Trading book, we have defined;

• Currency = EUR & USD
• Currency pair = All
62
Notes:
• Product = Swap
Once you have defined the above, apply the ‘Save’ button to save your configuration.
An example of how this would be used would be; let’s take our trader x. If trader x, who is part of
group cm_trader and wanted to trade a USD Swap using Equity Trading Book, then the system would
check:
• If cm_trader = as part of his/her Group Access had the access SaveTrade under the ‘Function’
heading
• If cm_trader = as part of his/her Group Access had read-write access to the Trading Book ‘Equity
Trading Book’ under the ‘Book’ heading
• If cm_trader = as part of his/her Group Access had read-write access to the Swap Product type
• If cm_trader = as part of his/her Group Access had read-write access to a static data filter that
contains the Swap
• If in the Book Access panel = the Equity Trading book had permission to trade the USD currency
• If in the Book Access panel = the Equity Trading book had permission to trade the Swap Product
(even though that is not what our setup shows)
• If cm_trader = had the permission to apply the NEW action on the Equity product
With our example above, trader x would not have been able to save the Equity trade regardless if
under the Product Types listed for the cm_trader the Group Access lists Equity and Swap. The Book
Access screenshot shows that Equity Trading Book has permission to trade only Equities.
Workflow & Task Action Access Rights

The Workflow Access panel has a two-fold functionality. This tab allows a user in a particular group to
define the actions he/she would like to apply on all products or on a particular product for
trade/transfer/message workflows as well as giving the user (at the group level) the possibility to
specify what tasks should be handled by the users. It is important to understand that these access
permissions are for users but at the group level.
An example of the first scenario would clarify point VII of our section 4 above where trader x tried to
save a trade. In that example, we mentioned he would not have been able to save the Swap trade for
two reasons.
Had there been a configuration already in place for the ‘Trade’ workflow (for a defined product
‘Equity’) which specified what workflow actions the user (trader x) was allowed to perform using the
Workflow Access panel, and that action was NEW, point VI would have been successful and the only
reason trader x wouldn’t have been successful would have been just Point VI.
63
Notes:
This functionality is very useful as it gives users within a group the possibility to determine the actions
they can conduct on the lifecycle of a task and also gives them the possibility to restrict access to
certain actions.
For example, where for a certain users group the actions EXERCISE, EXPIRE, TERMINATE or
CANCEL was not desired to be transacted by that group, this tool would be very useful as it allows to
define who (in which group) can and cannot transact these actions.
This functionality can be a form of implementing the four-eye principle on a workflow across groups.
We will be discussing this further during our Workflow module.
Trade/Transfer/Message buttons allow us to choose the main back office objects for which the out-of-
the box Workflow is defined. The Task button allows us to choose the tasks on these main Back
Office Objects.
Once having determined the workflow of a specific Back Office object (Trade/Transfer/Message), we
can select the group for which we will define the specific actions they are allowed to conduct on a
particular product.
If in section ‘a’ we had chosen Task, then the system allows us to determine what tasks users in a
particular group can conduct from the Calypso Task Station. Obviously, these users (via Group
Access and Functions) would already have to have the right to access the Task Station. We will
review the types of task in our module Task Station.
In our examples, read/write access to the Task Station has only been granted to the following groups:
• ta/middle office (thus = ta/middle office user 1)
• operational (thus = calypso_bo operations user 1 & 2)
• ops management (thus = calypso_bo management user 1)
64
Notes:
Duplicate/Add & Remove buttons can be used to manage the configuration desired. The results of
these buttons will allow users to view results in the table below.
The ‘Save’ button will apply changes to configuration.
65
Notes:
3.2 Static Data

The Back Office maintains the Static Data information of financial institutions. They are responsible
for inputting and maintaining the necessary & current information required (counterparty
name/contact/address/settlement information/legal documentation, etc.) which will permit the
Financial Institution to receive and deliver assets in a smooth and lawful (adhering to the
agreements/jurisdiction acts in place) manner.
Now that we have determined the architecture of Calypso, the design concept of a transaction and the
access permission setups required to get a user started, we can focus on the necessary data that
needs to be in place in order to do those transactions.
In general, the required Static Data of an Institution could be numerous but for all intents and
purposes, static data is ‘static’ and once input, back office users would not be adjusting/updating it on
a regular basis. Changes would be infrequent (although contract details could be less static) and
when necessary, updates would be on an ad-hoc basis.
Let us review the relevant Static Data that needs to be in place for our course. Static Data information
(time zone / domain data / country / currency / currency pair / holiday calendar / reference indices /
date rules) to be configured to get users started. For this course, we are assuming those are in place
thus we will only be addressing the static data that will come as useful for the purpose of this course.
Legal Data
Legal Entity
A Legal Entity in Calypso represents an independent business unit within or outside the organization
(Financial Institution). The ways in which Calypso determines how a Legal Entity/Business unit can be
involved in a trade is by defining the ‘roles’ the Legal Entity/Business unit plays visa a vie the
organization.
The ‘role’ given to the Organization itself is ‘Processing Organization’ (often referred to as ‘PO’ for
short) and this is the highest business unit of the banking organization.
Depending on the organization of the bank the PO can have one or several PO’s. Thus one
or several PO’s can be configured .
To configure Legal Entities, navigate to:
Main Entry > Configuration > Legal Data > Entities
66
Notes:
The short
name will
identify the
Legal Entity
throughout
the system.
Short Name
is usually the
abbreviation
of the Full
name.
The Legal Entity Window allows the Back office user to define specific details pertaining to each and
every Legal Entity/Business Unit that plays a part in a particular transaction.
Below is a list of the prominent information that you will need to know for this course, for further
information and full details of available fields, please review Calypso Documentation (section on
Defining Legal Entities).
Full Name
Most Institutions/Banks (although within the market may be known by their acronym) have an official
name under which they are registered. The full name field refers to this official name. An example
could be BNP, HVB or UBS where Banque National de Paris, Hypovereinsbank and Union Bank of
Switzerland are their ‘official’ names respectively.
Status
Users can select the status of a Legal Entity by using the drop down arrow on the Legal Entity window
next to ‘Status.’
A Legal Entity can have three different statuses:
• Enabled: Normal status for any entity. Unless a Legal Entity is enabled, the Legal Entity will not
be accessible in the trading windows to transact a trade. Once in Enabled, the Legal Entity is
active and trades could (in the case of counterparty) be booked against the entity
• Disabled: Status used when the user wishes to halt trading or other new business with an entity.
When an entity is disabled, the existing trades involving that entity will be left as is
• Pending: Used when creating a new entity (during input of a trade) and additional time is
required to verify the entity's details and acceptability. The entity in status ‘pending’ can still be
selected, but it will be flagged to signal the operations department that they should not approve
trades involving the entity
67
Notes:
Role
As discussed above, the ‘role’ represents the involvement of the Legal Entity in the trading process.
To define a ‘role,’ open the Select Legal Entity Role(s) window by selecting the ellipses button
(situated bottom of the Role window).
Use the Add Role

functionality to add
roles which do not yet
exist in the left
selection window. Use the arrows to
move roles from list of
available roles on left,
to selected roles on
right. Or vice a versa.
Roles used when transacting a trade:

• Processing Organization: Referred often as PO, represents the highest unit of the bank's
organization. Your organization is identified as the Processing Organization (owning trading books
in the system) while the other side of a trade is identified with the role of Counterparty
In some cases, the PO can also represent an external entity for which your organization
transacts or processes "in the name of..."
The PO has its own specific set of processing rules for the Back Office. The ability to Book
trades, manage the business flow of events associated with a trade (i.e., generate Messages,
make payments and generate Accounting is interlinked to the role Processing Organization
role.
• Counterparty: Addresses the facing party on the other side of a trade/transaction. This can be
an internal entity or an external entity
• Clearer: Defines a clearinghouse for futures and options. In Calypso, when transacting a trade
for these products, trades will face ‘Clearer,’ rather than ‘Counterparty’
• Client: Defines Legal Entities for which the Processing Organization holds an account. In this
case, (i.e. Interest Bearing trades), trades will face ‘Client,’ rather than ‘Counterparty’
Roles used for payment purposes:
68
Notes:
The Back office is responsible for making all payments / receipts for the bank. Apart from the
payments due / received to / from the counterparties with which a trade was transacted (or any of the
other roles listed above), payments / receipts could also be to /from custodians, brokers,
intermediaries, government agencies and exchanges.
• Agent: An organization to whom or from whom cash or securities will move; nostro, custodians,
clearing house and cash correspondents are agents. When you define the Settlement Instruction
in Calypso, you can add agents for any Legal Entity
For a full list of available roles, please review Calypso Documentation (section on Creating a Legal
Entity).
Contact
The contact button will open up the contact window from which users will need to define the
department / person within the bank (PO) organization and at the counterparties, agents, etc., who act
as contacts in all trade-related activity (payments and confirms).
You can assign a Identify the Legal

contact to be Entity/ role for
applicable to specific which you are
PO’s or in saving Contact
scenarios. details. You can
specify if this
contact will be
used as contact
across products
When messages or all products
(verification/con and the
firmation) department of the
messages are contact.
created by
Calypso, they
will be created
and sent to the
address listed
here.
For a detailed explanation of specifying Contacts, please review Calypso Documentation (section on
Contact Information).
This window is also accessible via Main Entry > Configuration > Legal Data > Contact Personnel
Attributes
The attributes button will open the Legal Entity Attributes window. Legal Entity attributes serve two
purposes. They can be used for reporting purposes (thus no specific code behind an attribute) or can
69
Notes:
be used for enhancing a specific functionality (these type of attributes are coded) changing the way in
which the system functions for certain trades/legal entities etc.
Example in screenshot above: should PO CAL BANK PARIS have a transaction with Legal Entity
BANK A (with BANK A’s role being Counterparty), then the system will activate (because the value is
YES) the logic ‘CLS.’
This window is also accessible via Main Entry > Configuration > Legal Data > Attributes.
Legal Agreement
The Legal Agreement button (via the Legal Entity window) allows organizations to define and store
the Leal Agreements in place between themselves and another Legal Entity
The legal department of a Financial Institution is responsible for making sure that the Bank’s
transactions adhere to laws under which the Bank is subject to. This could be global trading laws,
federal laws, national laws and / or regulations of the jurisdiction in which the bank is located. The
legal department is responsible for ensuring that the trades transacted by the bank abide the relevant
laws and that the interest of the Bank is also protected.
Depending on the products in question, some legal agreements are intricate (structured products) and
require in depth legal involvement from the legal department while others require less intervention
(ISDA agreements) due to their frequency and vanilla products.
The Legal Agreement window, allows a Financial Institution to stock (within Calypso’s platform) all the
Legal Agreements signed with a Legal Entity.
Agreements refer to agreements such as ISDA agreements for Swaps/Derivatives including DTCC
related transactions, Clearing agreements with CMF’s (referred to as FMC’s in Europe), CLS
agreements for related FX Clearing, GMRA / PSA / ISMA agreements for Repo, GMSLA agreements
for Security Lending etc.
The Legal Agreements button will open up the ‘Legal Agreements Window’ from which you can view /
edit and input relevant legal agreements according to your business needs.
Depending on the Agreement type saved for a certain product, there could be implications on the
behavior of the system. For Example; part of the eligibility check for CLS eligible FX trades is a check on the
existence of a CLS agreement between a PO and a Legal Entity for a determined currency. The
Repo/Security Lending trade windows show you if you have an agreement in place and Calypso derives some
values from the legal agreement. In addition, the Calypso Collateral Manager functionality uses the legal
agreement as a reference for a Margin Call contract and the messages created in association with that
contract.
Should you choose to upload the actual Legal Agreement documents for future reference you can do
so by clicking on the Documents button as shown on the screenshot below.
70
Notes:
The above screenshot is an example of a CLS Legal Agreement between Processing Organization
CAL BANK and Legal Entity BANK B. The Legal Agreement will be used by the system every time
CAL BANK and BANK B transact an FX trade.
The Documents button allows users to open up (review screenshot below) the ‘Legal Agreements
Document’ window. This window can be used in the event users (for their reference) want to upload
actual agreements into Calypso and assign them in the system with their corresponding PO/LE.
Each row shown below represents a page from the actual document. Double-click to launch the
document on the screen. You can upload documents in any format.
71
Notes:
This window is also accessible via Main Entry > Configuration > Legal Data > Agreements.
Detailed description of all other fields that exist on the Legal Entity window, (Country; country of the
Legal Entity, Parent; allows associating subsidiaries, Inactive As From; identifies the date from which
the Legal Entity becomes inactive thus unusable, Holidays; Holiday calendar that applies to the Legal
Entity etc.) can be found in the Calypso Documentation.
Class Related Legal Data Setup
To help us work through our exercises, we have saved a Legal Entity (role Processing Org) for
Calypso University Bank.
For the Processing org, we have established that the Short name to be used by the system is CUB.
We have identified that the Country of our Processing Organization is France and thus the holidays
EUR. This Legal Entity has been ‘Enabled’ thus for all intents and purposes, has been activated.
72
Notes:
PO: Calypso University Bank (CUB)
As explained in the above section ‘Contact’ our Processing Org ‘CUB’ will need to identify a contact
that will be used in the message details and also for Settlement Delivery instructions (we will review
Settlement Delivery Instruction in the follow modules).
Consequently, a Back Office contact (Jean Dujardin) has been identified to be the contact for CUB.
73
Notes:
Counterparty: Bank XYZ

CUB will be transacting trades. In order to do so, another Legal Entity needs to exist. The role of this
Legal Entity will be ‘Counterparty.’
Consequently, the Legal Entity Bank XYZ has been saved in the system (short name BK XYZ). We
have identified that the Country of this Legal entity is United States and the holidays NYC.
Just as the PO, this Legal Entity has been ‘Enabled’ (thus been activated) and a contact has been
saved.
74
Notes:
Agent: Chase
For the transacted trades between CUB and Counterparty BK XYZ, CUB will be using an Agent to
move/settle the Cash or Security involved from the transaction.
CUB’s Nostro Agent is Chase Manhattan Bank - New York, thus a Legal Entity for Chase has been
saved in the system. Like the Processing Organization and Counterparty, this Legal Entity has been
‘Enabled’ (thus been activated) and a contact has been saved.
Note that this Legal Entity has also role Counterparty. This will come up later in the course.
75
Notes:
76
Notes:
3.3 Reference Data

This section will cover only the Reference Data that is imperative for you to have in place in order to
allow us to continue following this course. For further details and other reference data’s supported by
Calypso, please refer to the Calypso Documentation (section on Getting Started > Reference Data).
As we will be inputting trades and reviewing the Back Office effects, we will need to define a trading
book. This will allow us to save our trades in a defined book and allow us to generate the required
settlements, messages and accounting that can be associated with a trade.
Trading Book Definition

Trades transacted by Banks are transacted using a ‘Trading Book’ A Trading Book is a collection or
‘portfolio’ of trades of financial instruments held by financial institutions. The ways in which trading
books are organized depends entirely on how the institution in question wants to represent their
trading activity and this can differ from one Institution to another.
For example, a trading book could be associated with a department of an organization (i.e., Global
Markets), or a particular division within the department (i.e., OTC Trading) or a desk/business unit
within the division (example; Swaps Trading/Options Trading). Thus; Trading Books generally serve
to classify trades (by type, customer, desk, financial goal, risk, etc.) as required by a financial
organizations reporting structure.
In Calypso, Trading Books are virtual entities created to represent an institutions ‘portfolio’ of trades.
Typically (again dependent on the reporting structure of an organization) an institution, has many
trading books (for example; one per instrument). This structure can be represented effectively in
Calypso.
In calypso a Trading Book can only be owned by one legal entity/one Processing
Organization.
While Calypso (as mentioned earlier) considers the Processing Organization to be the highest unit of
the Banking organization, it considers the Trading Book to be the smallest unit of the organization.
From a Back office perspective, in Calypso, the Trading Book servers several purposes. By default,
the aggregation level Calypso derives the Back Office P&L from is by trading book / product; you will
see this in action once we have transacted a trade.
In addition, Calypso processes the accounting on a trade, the settlements of a trade, generation of the
advice documents associated with it and the end of day valuation processes, based on the
Processing Organization for which the activity is associated with BUT, the link to the Processing
Organization is via the Trading book in which the trade is transacted/held.
Although the configuration/link for the settlements and the generation of advice documents for
a Processing Organization takes place at another stage, the link for the accounting process occurs at
the Trading Book configuration level. You will view the link in point 3 (Trading Book section) below.
77
Notes:
To save a Trading Book, Navigate to;
Main Entry > Configuration > Books & Bundles > Trading Book
In order to assist us in our exercise for our Back Office example, we will save two trading books.
Below you will view an Equity Trading Book:
and an OTC Trading Book.
78
Notes:
Description of the relevant fields in the Book window has been explained below;
• The field Name field allows you to enter the name of your Trading Book like the one showed
above, Equity Trading Book (for example)
• Activity field is free format. This could be anything based on your organization and the use of
this particular trading book, i.e., such as Swap Trading/Bond Trading/Book 121 etc
This field can be used for creating Book hierarchies. Books can be organized in Book
hierarchies for reporting purposes. Book hierarchies allow you to define the aggregation
levels of Books, based on Book criteria and they do not constitute a parent-child relationship
between Books.
• Should accounting entries be required users would need to link their accounting books (review
setup of an accounting book in the Accounting Book section below) to the trading book in the
Accounting Link field. For example; CALYPSO UNI BANK
• The Legal Entity against which the Trading Book is associated should be defined in the Legal
Entities field by clicking on the ellipses . For example; CUB
• The Legal Entity is the owner of the book. The owner must be a legal entity assigned to the role of
ProcessingOrg
79
Notes:
• The Location label allows you to select a time zone that represents the geographical location of
your Book. You can do this by selecting from the list in the drop down
• The End Of Day, allows you to enter the end–of-day time of your selected time zone
• For the Back office end of day processing, the trades or positions that are within a trading book
are valued using a process known as Trade Valuation or Position Valuation. It is very important to
note that the Trade Valuation uses the Location and End of Day (EOD) settings to determine
when a trade actually belongs to the Book
The ellipses next to the End of Day field allows you to define specific EOD times for specific
dates.
The system derives the EOD time for valuation purposes in the following order:
a) Use the time configured for the current/valuation date in the "Variable EOD" window if available
(launched from Book Window next to the End Of Day field (...)).
b) Use the time configured for the current/valuation date in the "LegalEntityEODTime Window" if
available (Menu Configuration > Legal Data > EOD...).
c) Use book "End of Day" field.
The above sequence is a different for liquidation comparator method type TradeDateFixed, the
"LiquidationTime" book attribute is checked first, and then the same logic as above applies.
• The Base Ccy field allows users to define the working Currency of the Trading Book. This is the
currency into which foreign currency amounts should be converted into. Example; EUR
80
Notes:
The End of Day Trade Valuation can be carried out in trade currency, base currency, or a user-
defined currency.
.
• Determine the holiday dates adhered by your trading book (ie. PAR) using the ellipsis next
to the Holidays field
• Select Save to save the Trading Book
The Book ID number is automatically assigned by the system when the book is saved.
.
Accounting Book
In Calypso, should accounting generation be desired, users will need to define an Accounting Book
against which a Trading book can be linked.
Main Entry > Configuration > Accounting > Books
An accounting book groups a set of trades that will be handled by the same set of accounting rules.
• Each accounting book will contain one or more trading books
• Accounting books allow the link between an accounting rule and the activity of the book
The illustration below shows how Trading Book activity is monitored in the Calypso Accounting
Framework.
An Accounting Book defines one of several accounting strategies that comprise a complete set of
accounting treatments for various products, currencies, desks, regions, or other trading criteria.
81
Notes:
When you create an Accounting Book, you are actually creating a name (label) for an Accounting
Strategy that will be applied to all postings that are created from Trading Books associated to an
accounting strategy.
Financial instruments are classified into four categories that have their own set of accounting
strategies; Fair value through Profit & Loss (FVPL), also known as Held-For-Trading (HFT), Held-to-
Maturity (HTM), Loans and Receivables (LAR), and Available-for-Sale (AFS). Usually, each category
is identified by a separate Accounting Book. Calypso allows you to define your accounting books and
associate them with your desired accounting strategies via:

Enter the name
relevant to your
accounting book.
Note: Comment
Use the
field is free format.
Classificatio
n to define
Accounting
Strategy,
Use the below

buttons to manage
your accounting
link window.
Once you have created your Accounting Book, you can now make use of it in two places. The first
being the Trading Book and the second being an Accounting Rule. Accounting books allow the link
between an accounting rule and the activity of the book.
Once an accounting book exists and it is linked to a trading book, providing the accounting book is
linked to an appropriate Accounting rule, Calypso will generate the necessary accounting entries
when a trade is transacted for a particular Processing Organization.
Should you need further information on Accounting Book definition / Strategy and
Accounting Rule please refer to the Calypso University Documentation and / or the Calypso
University Accounting Course.
82
Notes:
Module 4: Components of a
Trade
• Explain what back office components get generated when a Trade

is saved
• Review Transfers
• Review Messages
• Review Postings
MODULE 4 Components of a Trade
Introduction
We have identified the events that occur in a typical high-volume financial institution during the
transaction of trades (before the Back Office comes into play), the roles and responsibilities of the
Back Office, the architecture and design (separation of trade/product) of Calypso, and the various
data items that must to get started. Now, we will review the different components of a trade and
review how Calypso addresses these from a Back Office perspective.
This module introduces two trade examples; Equity and OTC trades. These trades will be used during
this course to highlight the main Back Office structure and to show the ways in which Calypso
addresses the different components of trades once a financial transaction has been booked.
84
Notes:
4.1 Trade
Components of a Trade
Irrespective of how the Back Office has received the feeds from a transacted trade (direct trader input,
trading assistants or electronic feeds), once it has been transacted and booked, regardless of the
asset class (Equity/Fixed Income/FX/Commodity/Interest Rates), there are certain aspects of the
trade that remain somewhat generic.
The trade will have a Counterparty; an exchange of an asset of some sort will be involved and the
trade will go through one or more lifecycle events (Initial transaction/confirmation/reset/exercise/
expiry/settlement/cancelation). Whether it is for internal or external use the trade must be recorded
and managed up until settlement and delivery.
Once a Legal Entity is created for the Counterparty, identification of the Counterparty, at least
by name at this stage, is done in the Trade Window.
Let’s assume Trader X working for Processing Organization CUB (Calypso University Bank) has
executed two trades (Equity and a Swap) with Counterparty Bank XYZ and these trades have been
fed into Calypso.
Example Equity Trade

Trade Date: 19 March 2012
Settle Date: 19 March 2012
Processing Org: CUB
Trading Book: Equity Trading Book
Trader: Trader X
Buys/Sell: Buy 50 shares of Peugeot
Price: 3.7
Counterparty: Bank XYZ (BK XYZ)
Currency: EUR
The trade details have been captured in the Equity Trade Capture Window as per the screenshot
below.
85
Notes:
Trade
Status
Example OTC Trade

Trade Date: 19 March 2012
Start Date: 21 March 2012
Settle Date: 21 March 2022
Processing Org: CUB
Trading Book: OTC Trading Book
Trader: Trader X
Buys/Sell: Buy 5mill 10yr Swap paying semi-annual act/30 vs. 3m Libor quarterly act/360
Price: 5%
Counterparty: Bank XYZ (BK XYZ)
Currency: USD
86
Notes:
Taking into account how we discussed the Calypso seperation of design in our earlier module, we
now know that as soon as these trades were saved, Calypso would have taken these two
transactions and seperated the ‘Trade’ from the ‘Products.’ These two trades give us an Equity
product (ISIN FR0000121501) that can be traded many times and also a Swap which is a one-off
instrument.
In a bank, once trades are executed, they could go through various checks before they can be viewed
as verified/confirmed. Depending on the financial institution and business practices at that institution,
the checks/additions could be of various types on and before a trade is considered ‘booked/confirmed’
(at least from a Back Office prespective), the trade could go through various statuses.
For example, a trade could be initially input by a trader but always held in a certain interim status until
the Trading Assistant has fully checked out the trade details with the broker/exchange through which
the trade was transacted.
Or, the trade could have been input but not considered as fully booked thus held in a ‘pending’ status
until the Middle Office has confirmed the information versus the actual trade tickets written by the
Front or Trader’s blotters.
Or, if a broker or a sales person is involved, the trade will need additional information, such as the
broker name and fee to broker, or sales person’s name and sales margin due.
The stage in which a trade is at, along the conveyer belt of a financial insitution’s ‘business practice’ in
Calypso, is identified by something known as the Trade Workflow status. We will cover this concept in
detail in the Workflow module, but at this point, the trade status will evolve along the lifecycle of a
trade and will differ depending on the asset class.
87
Notes:
For now, it is sufficient to understand that in Calypso, when a trade reaches a user-determined status
(in our two examples ‘VERIFIED’ status), various Back Office processes are triggered.
Back Office Window

The triggered/generated processes can be seen by opening either the Back Office window directly or
the Back Office window from any trade window using the menu item Back Office.
Using the Back Office window, users can perform several tasks, here are a few:
• View the Trade Transfer Rules in order to check that all settlement/delivery instructions are
correctly defined
• View the messages linked to the trade or trade related activity
• View the Accounting Book of the trade
• View the Accounting Entries related to the trade and trade related activity
• View the sell or buy trades offsetting the trade
• View the tasks related to the trade
• Add additional information (such as external or internal reference numbers or keywords)
• Change settlement parties relevant to the trade in order to settle the trade using different Legal
Entities
The Back Office Windows give users full-

access to specific back office details of the
trade.
88
Notes:
4.2 Transfer
The Back Office window consists of several tabs. We will first review the Transfers Tab.
A transfer is a movement of cash or securities from one organization to another (mainly as a result of
th
a trade). If we take the Equity trade example, you will remember that on the 19 of March 2012, CUB
had bought 50 shares of Peugeot at 3.7 from Bank XYZ.
th
The Equity (security) was to settle on the 19 of March 2012.The screenshot above shows the
generation of the transfer in question between these two parties.
In Calypso, several events determine the generation of Transfer(s), of which one (booking a new
trade) is what we conducted above. Other factors that determine the generation of Transfer(s) are:
• Carrying out a corporate action on a held product
• Resetting the rate on a floating rate trade leg
• Liquidating one trade against another
89
Notes:
Delivery Types
Each transfer generated in Calypso is assigned to a particular delivery type. Either it is a DAP
(Delivery Against Payment) or a DFP (Delivery Free of Payment).
DAP is a simultaneous exchange of payment against the delivery of securities. The receipt of
securities guarantees the payment of funds. This eliminates the risk that one party of the transaction
default to the disadvantage of the other party, who has or will settle their side of the transaction, i.e., if
payment is made then securities will be received and vice a versa. Thus transfer is made in "a single
step" (at the same time).
DFP is when the cash and the security transfer happen at different times, and thus are riskier for a
bank as they can fail independently. Let’s take an FX trade as an example where their normal FX
settlement is DFP. A EUR/USD trade could have been transacted by a US bank and Euro bank and
the US bank may have paid their EUR and the European Bank was expected to make their USD
payment later. This introduces a settlement risk as it could well be that the European bank declares
bankruptcy before paying.
Clearing Houses/settlement systems such as CLS provide a DAP settlement for FX trades. CLS, for
example, provides a means in which to simultaneously exchange the two payments involved in the FX
transaction, thus allowing the delivery and receipt of guaranteed funds. The benefit of this is also that
it eliminates the possibility of one of the parties of the transaction defaulting putting the other
counterparty at a disadvantage as he may have settled his side of payment. So this guarantees that if
payment of a sold currency is made, then the purchased currency will be received.
Either both transfers settle or neither does.
For DAP payments, you need a Clearing Agent/exchange between the Processing Organization and
Counterparty, handling the cash and security. You must also have accounts there. When there is a
transfer, as soon as there is a SECURITY cashflow involved, the default behavior is to set the delivery
type to DAP. When a cashflow is CASH only (with no SECURITY flow on the same value date),
Calypso assigns the delivery type to DFP. This usually applies to coupons, interest, fee rebates and
simple cash transfers.
Navigating to the Transfer Rules Tab in the Back Office Window allows us to see this logic applied on
the transfers of our Equity trade and Swap trade from earlier. You will see that the Equity transfer
(which involves a Security transfer), is assigned with a delivery type DAP while the Swap (interest
payments) with delivery type DFP.
Delivery
type set to
DAP on
the Equity
transfer.
90
Notes:
Delivery type
set to DFP on
the Swap
Interest
transfer.
Transfer Types
To represent the movement of Cash and/or Security, Calypso generates several types of Transfers.
These can be dependent on both the asset class and the reason for the initial transaction.
For example, if we take the Equity and Swap trades and review the Back Office Transfers Tab, for
these, we would see that Calypso, for the Equity has generated a Transfer Type ‘SECURITY’ and for
the Swap a Transfer Type of ‘INTEREST.’
This is in accordance to the asset class and the type of flow these movements are related to.
Equity Transfer Type SECURITY
Swap Transfer Type INTEREST
91
Notes:
Some of the main Payment/Transfer types Calypso generates are listed in the table below.
Payment Type Description
INTEREST Interest payment
PRINCIPAL Payment or repayment of principal
SECURITY Transfer of any item of value other than cash. For example, the transfer of a
bond.
EXERCISE FEE Option exercise fee paid at time of exercise.
PREMIUM Option premium, generally paid at the start of the deal.
COMMISSION Commission fee.
BRK Brokerage fee.
FEE Fee of any other type.
Other Transfer types related to Termination Fees, Variation Margin Fees, Execution Fees, Coupon,
Clearing Fees also exist, however the list above has been given to give you an idea of the range and
some of the main ones.
Transfer Category
Each flow type generated is assigned into one of four categories. This is dependent on the direction of
the flow (pay or receipt) and the type of flow (cash or security).
Let’s again take our two trades into consideration. The transaction of the Equity trade was purchase
of security vs. cash. The Swap trade is Pay Fix/Receive Floating. Thus meaning buy fix, sell floating.
For these two trades, the flows associated will show for the Equity a purchase of security and for the
Swap, the initial cash being received for the one leg vs. the other cash flows.
To represent this, Calypso categorizes the flows into what is known as Event Type.
92
Notes:
Equity Event Type SEC_RECEIPT
Swap Event Type RECEIPT

For the first flow period and PAYMENT for the remaining periods.
Transfer Category Description
PAYMENT An outbound currency payment paid by a unit of the Processing

Organization (usually your organization).
RECEIPT An incoming currency payment that the Processing Organization will

receive.
SEC_PAYMENT An outbound transfer of a security or other thing of value, being transferred

from the Processing Organization.
SEC_RECEIPT An incoming transfer of a security or other thing of value, being received by

the Processing Organization.
93
Notes:
4.3 Message
Saving the Equity Trade generates a confirmation message for the trade and for the transfer. The
Message tab in the Back Office window allows us to see messages associated with a particular trade.
In the same way, saving the Swap trade generates messages. We have generated the following types
of messages:
• Trade confirmation message and payment/receipt advice messages to the counterparty for the
transfers to be exchanged
• Payment/receipt orders to the agents
Calypso uses the term ‘Message’ to cover any communication that is produced and sent to another
party inside or outside the organization.
94
Notes:
In general, a message alerts an organization that a particular event has occurred on a trade,
payment, position, etc. As seen in our screenshots and also reviewed in the table at the bottom of this
section, an example of a message include:
• A simple ticket
• A confirmation
• A payment advice
• A payment order
• Rate reset advices
• A cancellation notice
Let us review the confirmation message (id 15609) for the Equity trade. This is a 'record' of the terms
of the Equity transaction. This confirmation is sent out by CUB (in practice each party involved in the
transaction needs to send their confirmation).
Before this confirmation, traders/trading assistants have generally already confirmed the transactions
of traders via Reuters/Bloomberg/Squawk boxes and/or other media. These confirmations, however,
do not constitute a proper/official confirmation.
In banks, the confirmation process is an activity entirely performed by the operations. The
confirmation allows a way for the back office to double check (reconcile) against trade errors and is
independent of the trading desks. We mentioned in an earlier module that the back office performs
their ‘tying out’ and notifies the trading assistant/trading desk in the event of breaks. Should the
incoming confirmation (from the Counterparty) not correspond to the outgoing confirmation
(information filtered down by the trading desk), the Back Office Operations department is responsible
for signaling this break.
In general, the data within the confirmation is obtained from third-party Back Office (payments
systems) institutions. At the minimum, the confirmation would incorporate details of the counterparties
involved in the transaction, the location, broker (if appropriate), transaction date, value date, currency
amounts (bought and sold), exchange rate, and settlement instructions.
Back Office users are responsible for checking inbound confirmations carefully when they monitor all
unconfirmed transactions. Risk in the confirmation process occurs if discrepancies are missed or
when transactions are not confirmed. In the event of such a case, each institution has its own
procedure for the escalation process.
Messages can be in various formats. The most common forms of confirmation by institutions are;
phone, mail, fax, telex and SWIFT (Society for Worldwide Interbank Financial Telecommunications).
SWIFT is the preferred method. This is because SWIFT messages have standardized formats across
asset classes for institutions to follow thus facilitating the usability and reconciliation process. This has
allowed institutions to adopt or build automation reconciliation tools and to automate confirmation
matching. Some SWIFT message types are:
MT000-099 System messages

MT100-199 Customer transfers, checks
MT200-299 Financial institution transfers
95
Notes:
MT300-399 FX, FX options, loans, deposits, FRAs, interest rate swaps

MT400-499 Collections, cash letters
MT500-599 Securities
MT600-699 Precious metals syndications
MT700-799 Documentary credits, guarantees
MT800-899 Travellers checks
MT900-999 Balance reporting, rate changes, Nostro statements
Below is a list of some of the Message Types Calypso generates.
Message Type Description
CONFIRM Trade Confirmation.
PAYMENTMSG Instruction telling agent to pay currency.
RECEIPTMSG Instruction telling agent to receive currency.
PAYMENT_ADVICE Reminder to counterparty concerning upcoming payment will be paid to

counterparty.
RECEIPT_ADVICE Reminder to counterparty concerning upcoming payment that the

counterparty must pay to PO.
SEC_DELIVERYMSG Instruction telling agent to deliver securities (Against or Free of Payment).
SEC_RECEIPTMSG Instruction telling agent to receive securities (Against or Free of Payment).
RATE_RESET Message to Counterparty that floating rate payment has been reset &
calculated.
EXERCISE_NOTICE Message Confirming that an option has been exercised.
SUPPLEMENT Supplement to a trade confirmation.
TICKET Trade ticket for internal consumption by own organization.
ACC_STATEMENT Produces reports based on a Statement Event. The purpose is to send a

Statement to a Client Account.
The statement frequency is set on the Account attached to the client. The
Statements request are generated by a new Scheduled Task
ACCOUNT_STATEMENT.
96
Notes:
4.4 Postings
By saving the Equity trade, the ‘event’ has generated an Accounting Entry. In Calypso, we call this a
Posting. The Postings related to a trade can be viewed via the Postings Tab in the Back Office
window.
Financial Institutions need to generate accounting entries that comply with their state and federal
(example Federal Reserve Bank) regulatory agencies. The regulatory agencies monitor the
compliance and integrity of a bank by reviewing the financial institution’s transactions (held on
accounts) in the general ledger.
Calypso generates entries made to ledger accounts (represented in Calypso) for all trading and
processing activities and integrates these into the bank’s general ledger system.
Calypso is capable of producing accounting entries in response to numerous transactions; saving a
trade, valuation associated to trades/positions held, payments made and a range of trade’s lifecycle
activities such as exercise, termination, premium discounts.
In general, accounting methods vary depending on several aspects:
• What has been traded (one asset classes accounting method will be different from another i.e.,
Equity from a Swap)
• Why the trade has been traded (two identical deals, one done for trading purposes and one for
hedging purposes may receive different accounting treatments)
• Where the trade has taken place (different countries have different accounting rules)
• Which organization has traded it (Calypso may generate postings for multiple legal entities, each
with its own accounting polices)
• Who the trade is with (the policy may vary depending on the type of the counterparty)
97
Notes:
Module 5: Generation &
Breakdown of Components

• Explain how Transfers are generated
• Determine Use of Transfer Engine
• Describe Role of Transfer Rules & Events
• Determine use of SDIs
• Detail how Messages (Trade and Transfer Related) are generated
• Determine use of Message Engine & how to configure it
• Determine use of Message Events
• Explain use of Legal Entity Contact information
• Explain how Postings are generated
• Explain the Role of the Accounting Engine
• Explain the Link between Accounting Rules, Books, Events &

Accounts
MODULE 5 Generation of Components
Introduction
Now that we have reviewed some of the Back Office applicable components that are generated when
a trade is saved, we can start running the Transfer, Message and Accounting engines so that we can
drill down and review how these components are actually generated, their dependencies and the
design/logic Calypso applies for each one.
The system will use configured information to when generating these objects. The trade and transfer
messages send throughout the system depend on this information, usually consisting of contact and
account information for the financial institution transacting the trades.
Continuing to use our Swap and Equity trade examples (which we will refer to frequently), we will walk
through this process.
99
Notes:
5.1 Explaining the Generation Process

Transfer
In Calypso, a transfer is generated with the correct information, provided several aspects are in line.
Below, we will talk about the various parts needed for generation.
Transfer Engine subscribes to a specific event

Let’s take the example of our Equity trade from earlier which generated a security type transfer when
the trade was saved. In an earlier module, we mentioned that Calypso’s architecture is based on a
publish-subscribe logic. We see this logic being applied here. The Transfer Engine has subscribed to
a particular event, PSEventTrade. When the PSEventTrade event is generated and published, the
Transfer Engine, due to its subscription of this event, wakes up and consumes it. The result of
consumption is the generation of the transfer.
To review configuration in place for this navigate to:
Select the event class that you would like an

engine to subscribe to and using the
‘Consumer’ field to link the Engine in question.
Use the ‘Add’ button to ensure your selection
is taken into account before saving your
configuration using the ‘Save’ button.
1. Navigate to the ‘Filters’ Tab
100
Notes:
By indicating the filter ‘VerifiedEventFilter,’

we determine that the Transfer Engine
generates transfers only for Trade Status
VERIFIED and not before (i.e. PRICING /
PENDING)
The Transfer Engine can subscribe to the following events:

• Trade events
• Price Fixing events
• Rate Reset Events
• FX Rate Reset events
• Liquidation events
In Calypso, for transfers to be created, the Transfer Engine needs to receive an event. Once the
– Engine receives the
Transfer Process trade
event, eventson what is known as the BOProductHandler. The
it calls
BOProductHandler is the ‘generic’ class for all the Back Office handlers. Within the generic
BOProductHandler, each product in Calypso will usually have its own specific handler.
In the Filters panel, review the filters associated with the transfer engine.
A BOProductHandler can be defined by Product Family/Product Type. During the processing of a
trade, if the system does not find the handler that matches the product’s Product Type, it will look for
one which matches the product’s Product Family.
– VerifiedEventFilter - It accepts any trade (except for trades in status PRICING or PENDING). Note that
When event
therefilters
is an can
event (in our case, a trade is saved as PSEventTrade) and the Transfer Engine is
be customized
awakened, the Transfer Engine calls on the BOProductHandler. The BOProductHandler uses the
specific product (family/type) of the trade to obtain the required trade cashflows (or adds the security
flows if necessary) and generates transfers. Thus, the Transfer Engine will use a Product Handler to
generate/define the transfers.
The result of this is what is known as Calypso’s BOTransfer object. The BOTransfer object in Calypso
is the universal representation of a thing of value (cash or security) created from trade cashflows (or
security flows if the Product on trade is security based) and forms the basis of transfers and risk
analysis but is a separate object.
101
Notes:
Trade
Generation
BOTransfer
Transfer Rules & SDIs

Once the Transfer Engine has received an event and the BOProductHandler has used the cashflows
of trades (or added security flows when necessary) to create the BOTransfer object associated with
the transaction, we technically have transfers. However, as transfers represent an exchange, logically
(and especially from a Back Office perspective), there would be no point in having transfers without
knowing who the exchange is with, i.e. without knowing who the bank is paying/receiving. Thus, there
needs to be a way for Calypso to associate the transfers with the relevant pay/receive instructions.
Calypso does this by assigning SDI’s to cashflows. SDI stands for ‘Settlement and Delivery
Instructions’ and is used each time the system needs information concerning the transfer of cash
and/or securities. The purpose of the instructions is to answer the question, "When I need to transfer
(or receive) cash (or securities) to (or from) somebody, how will the cash or securities travel between
me and the other person?” The response given by the SDI will include the following details:
• Who are my agents (and in some cases, who is the intermediary of my agent if I am using a
central agent to maintain my accounts) and which are the accounts into which the money or
securities should go?
• Who are the agents of the external entity who is sending (or receiving) money (or securities) and
which are the account into which the money or securities should go?
In the same way that you would need the bank name, the receiver’s information and the routing
information, transferring funds into someone else's accounts or when you give your bank details for
transfer into your own accounts, an SDI would contain the rules that tell the system how to move
funds and/or securities between organizations. SDIs can also apply internally to organizations,
directing how items are moved between books or desks, etc.
Technically, only having the trade cashflows and SDIs would mean that Calypso would need to assign
SDIs as many times as cashflows. Should a trade have many cashflows (a Swap for example);
assigning pairs of SDI’s to individual cashflows would prove costly.
As part of the SDI optimization technique, Calypso generates & assigns what is known as ‘Transfer
Rules’ (using SDIs) to cash or security flows which make up the transfers. This allows Calypso to
select only the relevant SDI for all the cashflows that fall within the same Transfer Rule instead of
assigning SDI’s for each cashflow.
102
Notes:
Settlement Delivery Instruction

For financial institutions, one of the main advantages of having preconfigured SDI setups is that it
provides a means to preauthorize the address and contact information of where transfers should be
exchanged, reducing the possibility of fraud issues or serious financial consequences from errors
which stem from confirmation of instructions exchanged on a deal-by-deal basis.
Having automatic setup and prioritization of SDIs provides various benefits:
• Reduces time and effort of deal input
• Eliminates the exchange of information on phone between front office and back office (thus
adding an automated aspect to this part of processing which will as a result reduce costs for
banks)
• Reduces confirmation discrepancies and as a consequence reduce the time/effort taken to resolve
them
• Confirmation discrepancies will be detected in a better manner, thus reducing risk
In Calypso, SDIs are configured for legal entities. In our previous Module (section on Static Data), we
reviewed how to set up legal entity information for our Processing Organization CUB and also for
Counterparty Bank XYZ. When defining these legal entities, one of the details that we also need to
define is SDI’s for each of these parties. We will review that here in this section.
To review our configuration, navigate to:
1. ‘Load’ Processing Org CUB using the Legal Entity Chooser window
103
Notes:
Once you have loaded Processing Organization CUB, you can access the SDIs linked to this
Processing Organization via the SDI button (as per the below screenshot).
104
Notes:
You can also access the SDI window directly via:
Main Entry > Configuration > Settlements > Delivery Instructions
The configured SDI window below shows an example of the SDI saved in the system for Processing
Organization CUB.
In Calypso, SDI's are composed of:
• A unique identifier (SDI id)
• Fields determining WHEN the conditions in which this SDI should be applied (explanation of some
of the fields is given below)
• Actual settlement instructions (agents and accounts)
When these elements are combined, they allow Calypso to retrieve all information required for a
transfer of cash or securities to a particular account via a particular delivery method. For example,
"pay via SWIFT into my Cash Account 0345-56783 at JP Morgan Chase."
105
Notes:
1 3
If the Beneficiary is a
PO, use the ellipses
button to select the
4 6
account
2 name/number held
at the agent of the
processing org.
3
Refer to section
on ‘Accounts’ for
further details.
Our settlement instruction for CUB has been defined with the below conditions:
1. The beneficiary Legal Entity name (CUB) and the role of that legal entity, Processing Organization
2. The name of our agent (this could have been an intermediary should that have been applicable)
3. The contact type (Back Office) at our organization who handles payment documents and the
contact type at the Agent (Payment) that handles theirs
4. The account number at our agent (or intermediary should that have been applicable) that will be
affected. The accounts specified here are only used in the messages sent to agents and/or
counterparties and not accounting rules
5. The Settlement Method is the method that corresponds to the network or other means by
which the funds or securities will move. This field allows the system to match the SDI of the PO and
the counterparty. For example, the message type SWIFT, CLS, etc.
106
Notes:
6. A flag to indicate whether the agent and intermediary should receive payment advices. By default this
is checked if role is set to Processing Organization
If role is not Processing Organization then a flag (review screenshot below) will be available for
users to indicate whether the beneficiary is a client of the Processing Organization. This means the
settlement will be done directly with the PO. This will indicate that the cash/security of the particular
Legal Entity will be settled in an account held directly at the Processing Organization. Example:
Should CUB transact a trade with Bank XYZ and Bank XYZ holds their account at CUB then when
defining Bank XYZ’s SDI, this flag would be checked.
The settings underlined above (2 through 6) and the direct checkbox are used later for
settlement instructions themselves. Review the HTML generated message below.
In addition to the conditions we have defined above, the SDI settings can be fine-tuned using the
below additional conditions.
• The transfer type (cash, security or both)
• The direction of payment (pay, receive or both)
• One or more currencies
• One or more product types
• An effective date and/or an inactive date (optional)
• A processing organization (if the SDI is only applicable in case of a relationship between the
counterparty and a given processing organization)
107
Notes:
• A static data filter
• A priority
• A flag indicating if the settlement instruction is the preferred settlement instructions to be used (if
it will be included into the default search)
As a trade has two sides to the transaction, you would also need to configure a SDI for the
counterparty, agent, or any party attached to the trade. You would do this in the same manner as
shown above for the Processing Organization.
Displayed below is Bank XYZ’s SDI configuration:
Once trade cashflows (or security flows) have been used to generate transfers by the
BOProductHandler, if SDI setups like the are in place, Calypso will have the information it needs to
generate and assign Transfer Rules against transfers using the settlement instructions.
Calypso goes through the below process to apply Settlement Instructions to a trade:
1. Aggregates all cash flows/transfers related to the trade by type (cash/securities), sign (pay/receive) and
by beneficiary into different flow types
2. Attaches a trade transfer rule to every flow type
3. Selects the preferred/valid SDIs for filtering and sorting
108
Notes:
Keep in mind:
• SDIs that are active on the settlement date (or trade date)
• SDIs that satisfy the static data filter if any
• Ordering the selected SDIs based on their priority
The settlement instruction for the counterparty and the processing organization are hence sorted in
order to establish a priority order among them. From the filtered/sorted list, we will review the methods
specified for counterparty and processing organization. Calypso begins the matching process by:
Matching for the trade counterparty using the following criteria in the specified order:
1. Beneficiary role and Beneficiary
2. Processing org, or ALL
3. Cash / Security, or BOTH
4. Pay / Receive, or BOTH
5. Product types, or ANY
6. Currencies, or ANY
Matching for the processing organization using the following criteria in the specified order:
1. Settlement method of the selected counterparty’s SDI
2. Product types, or ANY
3. Currencies, or ANY
If no SDI is found for the same settlement method, Calypso investigates the possible routes using the
Settlement Instructions of the Agents performing the same comparison between methods.
Possible Scenarios Outcome
If no SDI found for Trade Counterparty The system searches SDIs for its parent if any, or
(should the environment property
GET_ALL_BENEFICIARY_SDIS is set to true) for
the beneficiary “ALL” using the same algorithm.
If multiple SDIs are found for the trade The system will indicate that it cannot select the
counterparty (due to same keys) SDIs. You have to modify the priority for example,
so that the system can select an SDI, or the SDIs
have to be manually assigned.
If multiple SDIs are found for the PO (due to The system will select the first SDI found by
same keys) default.
If you would like the behavior to be that the
system indicate it cannot select SDIs (SDI
attribute "UseAgentAsKey needs to be set to =
false").
109
Notes:
The matching of SDI is always based on Counterparty first and then PO.
The result of this process would be the generation of trade transfer rules attached with settlement
instructions. The default function for each product in Calypso is to have one TradeTransferRule for
each unique type of cash or security flow in the trade.
When a correct SDI is found, the transfer rule will have a status attached to it. The status of the
transfer rule (hardcoded in Calypso) will be 'Default,’ indicating the affected settlement instruction is
the result of the standard searching algorithm. If there are no settlement instructions found by the
algorithm, the status is set to 'TBA' (To be Assigned). Should users assign the SDI’s i.e., in the event
that there were more than one SDI found with the same key and the user assigned the SDI to the
transfer individually, the status of the transfer rule will be set to ‘Xfer Assigned.‘
The Back Office Browser (via the ‘Transfer rules’ tab) allows users to view the Counterparty and
Processing Organization SDI’s. If using the Back Office window, this information can be retrieved via
the ‘SDI’ Tab.
110
Notes:
Once the Transfer Engine subscribes to the PSEventTrade and the Transfer Engine is processing the
trade for the first time, the Transfer Engine generates all Transfers attached to a trade from the
beginning of the trade. The BOProductHandler functions would be used to facilitate this.
The BOProductHandler will create all the transfers relating to a trade by using the cash or security
flows. The existence of correct Trade Transfer Rules (again, if settlement instructions have been set
up for the trade) allows Calypso to link transfers with their correct delivery instructions.
By this point, each transfer (the BOTranfsfer object) contains all the information required to carry out
the necessary Back Office processing (related to cashflow movements) in Calypso which rely on the
BOTransfer object. These processes are the generation of accounting entries, payment production,
and treasury/inventory position management. We will review this as we move through the module.
111
Notes:
The Transfer Engine generates transfers (except if the trade is in CANCELED status)
regardless if the system has found relevant SDI’s or not. If relevant SDIs do not exist, the trade
transfer rule will be in status TBA and the transfers would be generated but would be in INVALID
status.
If the Transfer Engine has already processed the trade in a previous session, it filters the transfers to
the ones having a settle date after or on the current date and which do not have a CANCELED status.
If the event is a PSEventProcessTrade, the limit date is specified in the event for back value payment
regeneration. Then the Transfer Engine compares the generated transfers to the existing ones and
matches them based on a set list of criteria (you can find this list in the Calypso Documentation). If a
transfer does not match, it is considered unmatched.
Message
In Calypso, messages are generated with provided the correct information and other items have been
defined and are present. In this section, we will cover how Calypso generates messages, determines
who the messages are for and associates them to physical/soft documents.
Message Engine subscribes to a specific event

Continuing on with our Equity trade from earlier which generated us two messages of the type
CONFIRM and SEC_RECEIPTMSG, let us review the setup necessary and the logic implemented by
Calypso for these messages to be generated. We will be focusing on what happens and what is
generated when the trade is saved to the system.
Primarily, the Message Engine would be susceptible to the same publish-subscribe logic discussed
during our previous module. For the CONFIRM message generated in our example, the Message
Engine would subscribed to PSEventTrade. When the PSEventTrade type event is generated the
Message Engine, due to its subscription of this event, wakes up and consumes it.
To review configuration in place for this, navigate to:
112
Notes:
Select the event ‘PSEventTrade’ in the

Event Class and assign the Message
Engine as a consumer in the Consumer
field.
Use the ‘Add’ button to ensure your

selection is taken into account before
saving your configuration using the ‘Save’
button.
Message Configuration
Once the Message Engine has subscribed to PSEventTrade and a trade is saved (triggering the
PSEventTrade), it will search to see if there is a Message Configuration defined in the system that fits
a certain search criteria. The search will query for the Message Configuration that applies to the
Roles/Legal Entities of the trade.
In our case, the legal entities involved are CUB (role set as Processing Organization) and BK XYZ
(role set as Counterparty). Calypso will find the processing organization involved on the trade via the
trading book used for the trade.
Calypso allows you to define message configurations via the Message Configuration window for ‘All’
or a specific Processing Organization by Product Type, Event Type, Message Type, Sender Contact
and Receiver contact. The Message Configuration window defines the details of the documents that
are sent to another party inside or outside the organization alerting them of an event that has
transpired.
To review configuration in place for our example, navigate to:
Main Entry > Configuration > Message & Matching > Message Setup
113
Notes:
4
1
Our message configuration for CUB has been defined with the below conditions:
1. The Processing Organization name for which the message is specified, which in our case is CUB
2. The Product Type field has allowed us to specify for our product for which we would like the
message configuration to apply, in our case Equity
3. The Event Type indicates which event will instigate the Message Engine and cause it to generate a
message. In our case, the event chosen is VERIFIED_TRADE
4. Message Type allows us to indicate the type of message we would like to generate when the
event (VERIFIED_TRADE) occurs. We have chosen CONFIRM, which implies the confirmation
message
5. PO Contact Type indicates who the sender contact is. We have indicated in the example above
that the sender contact is someone in the Back Office department
6. Receiver Contact Type allows us to indicate to whom the message will be addressed, and we
have configured ‘Operations’
114
Notes:
With the above configuration, we have already indicated that when our Equity trade reaches a
VERIFIED status, our Processing Organization would generate a confirmation message. The
confirmation will be sent from our Back Office department to our counterparty’s Operations
department.
Using the fields below, we can further define the details of the Confirmation itself.
3
4
1. Using the Language filed we can specify the language in which we would like the confirmation to
be generated
2. Address Type determines the address information the confirmation should use for the
counterparty (receiver) contact ‘Operations’
3. Gateway allows calypso to determine the means in which the message should be transmitted. We
have selected PRINTER, which means that the Processing Organizations ‘Back Office’ will send
the message confirmation using a PRINTER
4. Format Type allows us to determine in which format the message confirmation should be
generated. We have defined HTML
5. Templates contain free form text as well as template keywords to retrieve information from the
trade, message and transfer. These determine the form/template the message should follow. As
Calypso has a number of out-of-the-box templates (review the Message.Template domain for the
out-of-the-box list), we have chosen an existent template for Equity confirmations
115
Notes:
Calypso provides a list of out-of-the-box Gateways, Format Types and Templates. These
can also be customized. Refer to Calypso Documentation for further details.
Contact Information
In an earlier module, we reviewed how to set up contacts for legal entities and also saw an example
of how the contacts for our Legal Entities CUB and BK XYZ were set up. Using our legal entities as an
example, we will now show you how Calypso uses the contact details for the message generation.
A quick review of our Processing Organization Contact:
The sender (PO)

Contact Type on the
message configuration
above will retrieve
the correlating
contact type saved in
the Contact definition
The sender (PO) for the PO involved
Contact name will be in trade.
used for signing of the
confirmation message.
The Address Type on the

message configuration above
indicates ‘MAIL.’ Calypso
will retrieve Address
specified in the ‘Address’
section of the Contact
definition for the PO and
will use this address on the
Confirmation.
116
Notes:
A quick review of our Counterparty Contact: The Counterparty Contact

Type on the message
configuration above will
retrieve the correlating
contact type saved in the
Contact definition for the
counterparty of trade.
The confirmation message will
be addressed to the receiver
(counterparty) Contact name.

above indicates ‘MAIL.’
Calypso will retrieve
Address specified in the
‘Address’ section of the
Contact definition for
Counterparty and will use
this address for the
counterparty section on the
confirmation.
With the configuration setup like above, the Message Engine is able to create a shell (BOMessage
object) for the counterparty requiring the message with the correct information when a trade is saved.
Trade
generation BOMessage
We can see the message in the Back Office window > Message tab as per the screenshot below.
Here is an example of CONFIRM message generated using the equityconfirm.html template:
117
Notes:
The system will retrieve the contact

details for PO contact and Counterparty
contact mentioned in the Message
Configuration using the Contact
definition of the Legal Entities involved.
Transaction (Trade id) will be mentioned

as well as the details of the transaction
(Product and Financial details).
At this stage, for trade messages, the

Message Formatter (which can be
launched from the client when we show a
document from the main entry) adds the
SDI details for the Legal Entities involved
in trade.
Now let’s visit what has taken place for the generation of the second message on the trade. In order
to do this, we need to revisit briefly the subject of Transfers. We saw that when our trade was saved,
a transfer was generated. To show how Calypso did this, we had gone through the various stages the
Transfer Engine went through to create the BOTransfer object.
TheTransfer Engine, when a trade was saved for a PSEventTrade, called the BOProductHandler. The
BOProductHandler uses the cashflows from the product to create a BOTransfer object aligning the
correct SDIs to the BOTransfer Objects via Trade Transfer Rules. With this in mind, we can now
begin to review the second message SEC_RECEIPTMSG which originates from the created
BOTransfer Object.
For the generation of SEC_RECEIPTMSG as a starting point, the Message Engine would need to
subscribe to PSEventTransfer.
118
Notes:
Select the event ‘PSEventTransfer’ in the Event Class

and assign the Message engine as a Consumer in the
consumer field.
Use the ‘Add’ button to ensure your selection is taken

into account before saving your configuration using
the ‘Save’ button.
Then, in the same fashion as the PSEventTrade or CONFIRM message scenario above, the Message
Engine would conduct a search for a message configuration. This time however, unlike the
PSEventTrade scenario, instead of searching and retrieving the message configurations that apply to
the Legal Entities of the trade, it will search for the message configurations that apply to Legal Entities
of the ‘transfer’.
For the security transfer on the Equity example, there are three Legal Entities involved: CUB with the
role set to Processing Organization (for transfers of the internal legal entity), BK XYZ with the role set
as the trade Counterparty (for transfers of external legal entity) and Chase the role set as the Agent
(which is the agent specified in the SDI).
119
Notes:
For the SEC_RECIPTMSG, we have in place a message configuration defined with the below
conditions:
1. The Processing Organization name that needs to be involved in the transfer. In our case CUB and the
Sender Contact (PO Contact Type) to use in such circumstance as ‘Back Office’
2. Determining the Product Type as (Equity) indicates to the system that the transfer should have been
generated for product ‘Equity’
3. The Event Type indicates which event will instigate the Message Engine and cause it to generate a
message. In our case, the event chosen is VERIFIED_SEC_RECEIPT
4. Message Type allows us to indicate the type of message we would like to generate when the event
(VERIFIED_ SEC_RECEIPT) occurs. We have chosen SEC_RECEIPTMESG, which implies Receipt
message
5. Receiver Role and Contact Type allows us to indicate to whom the message will be sent to and
addressed to, and we have configured ‘Payments’
120
Notes:
The configuration above tells the Message Engine when a BOTransfer object (in this case, a transfer)
is of direction receipt and in VERIFIED status, should the transfer be for product type Equity and
Processing Organization CUB generate a message of type SEC_RECEIPTMESG. This done from
CUB using the Back Office contact details and it is sent to the Payments Department of the Agent,
which in our case is Chase Bank.
Thereafter, like for the CONFIRM message, the remainder section of the Message Configuration
window allows user and system to determine the properties of the message itself and the method to
be used to send the message. The fields are described below.
1
2
1. The Language field determines that the message will be generated in English (or any language
selected from the drop down)
2. The Address Type determines the address information the confirmation should use for the Agent
(receiver) contact ‘Payment.’ By now, you know this is in respect to the contact information on
the legal entity. Review below contact information section
3. We have selected that the message should be transmitted using SWIFT as Gateway. This means
that the processing organization’s ‘Back Office’ will send the message confirmation via SWIFT
4. The SWIFT format has been determined for the confirmation message
5. For the Template, we have chosen a template type ‘Payment.Selector,’ which allows the system
to automatically pick up the proper MTx92, MT202 or MT103 XML templates
Contact Information
Now that we have an understanding of the role messages play in Calypso, we will review contact
details for the message sender and receiver (Processing Organization and Agent) on the message
configuration that determines the contact information to be used on the message when being
generated.
Here is a quick review of our Processing Organization Contact:
121
Notes:
The sender (PO) Contact

Type on the message
configuration above will
retrieve details of the
correlating ‘Contact Type’
(thus Back-Office) saved in
the Contact definition for
the PO involved in the
transfer.
above indicates ‘SWIFT’
meaning Calypso will
retrieve the ‘SWIFT’
address specified in this
Swift field for PO CUB,
Contact type Back-Office.
On the Swift message
generated, it will use this
address for sender’s Swift
address.
And a quick review of our Agent Contact:
The receiver (Agent)

Contact Type on the
above will retrieve details
of the correlating ‘Contact
Type’ saved in the
Contact definition for the
Agent involved in the
transfer.
As the Address Type on the

message configuration indicates
‘SWIFT’ Calypso will retrieve the
‘SWIFT’ address for Agent Chase
contact type ‘Payment’ from
here.
With the above setup in place, when our Equity trade is saved and the BOTransfer object is created
(review previous section on the creation of BOTransfer), the message engine is triggered by a
PSEventTransfer.
122
Notes:
After the generation, the Message Engine would conduct its search for the correct message
configurations for the roles/legal entity the on transfer. If found, a RECEIPTMSG is created using the
correct address of the relevant Processing Organization for the transfer as Sender and the Agent as
Receiver.
Example of SEC_RECEIPTMSG generated as SWIFT message:

The system will retrieve the contact
details for PO contact and Agent
contact mentioned in the Message
Configuration using the Contact
definition of the
Legal Entities involved.
Transaction (Trade id) will be

mentioned as well as the financial
details of the transaction.
For the transfer message, the SDI

details are stored in the BOTransfer
Object and thus are obtained from
there.
Technically, when a trade/transfer is saved, the Message Engine calls the BOMessageHandler which
is the generic class for all the Back Office message handlers. A BOMessageHandler can be defined
by Product Family/Product Type thus for all intents and purposeseach product type in the system may
have its own BOMessageHandler, for example ‘BOFXMessageHandler’ or
‘BOFXSwapMessageHandler.’ When the system does not find a handler that matches the message's
Product Type, it will look for one which matches the message's Product Family or "N/A" for message
types without product type such as STATEMENT.
123
Notes:
The message, sent by the ‘Sender’ and destined ‘Receiver,’ carries along information, potentially
about the associated trade and transfer. The Message Engine will generate one or more
BOMessages by processing a received event using an AdviceConfig. The AdviceConfig is an object
which governs how to create BOMessages. It includes information obtained from the Message
Configuration (Receiver/Sender), related trade or transfer and the PSEvent that triggered the
processing.
The message engine can also subscribe to the following events:

• Rate Reset Events
• Price Fixing events
• Statement events
• Static Data Modification events
• Bundle events
Much like all engines, the Message Engine can also have filters defined to refine the parameters in
which it consumes events. Review the Calypso Documentation for full description of the above
events and detail on event filters applicable to the Message engine.
Posting
A posting (an accounting entry) is generated in Calypso when a business event occurs. In our case,
the business event that occurred was the Equity trade being saved. A trade being saved, being
valued, a rate being reset, interest being paid, etc. are all examples of business events that could
occur.
When business events occur, the Data Server takes this data and stores it. The Data Server passes
these events carrying this data to the Event Server. The Event Server thereafter publishes them to the
Accounting Engine provided the Accounting Engine has subscribed to them.
In the following section, we will be using our saved trade scenario to review all of the components that
needed to be in place for Calypso to have generated accounting entries.
Accounting Engine subscribes to a specific event

124
Notes:
Select the event ‘PSEventTrade’ in the Event

Class and assign the Accounting engine as a
Consumer in the consumer field.

The above configuration shows that the Accounting Engine has subscribed to the PSEventTrade and
when a trade is saved, the Accounting Engine will receive the information of the saved trade. The
Accounting Engine thereafter will start to review and filter through what is known in Calypso as
‘Accounting Rules.’
Accounting Rules & Books

An accounting rule defines the way in which the accounting activity should be addressed for a given
type of trading (or other activity) in a given category of products.
In general, an accounting rule serves a few purposes. The rules:
• Determine the type of accounting entry the system should generate. For example, users can
determine if entries are classical accounting postings or CREs
• Allows the possibility to determine the general accounting practice for a given processing
organization/region
• For example, we can use an Accounting rule to define the way in which the processing
organization books its Mark-to-Market (MTM). Users determine the general rule concerning the
accounting behavior by defining if MTM should be generated on a daily basis or on specified
dates, in which currency it should be generated and when it should be reversed
• It gives the possibility to determine the relationship between accounting events computed and the
accounts against which the events are booked
• For example, when a Mark-to-Market event (this being the Accounting Event computed) occurs, if
it is positive, create a CREDIT accounting event for the computed amount and book it in the
PROFIT account and DEBIT another account
125
Notes:
For a published event, the Accounting Engine filters through all the Accounting Rules available in the
system to find the applicable Accounting Rule with the correct accounting book, product and static
data filters.
To review Accounting Rules in place for this, navigate to:
Main Entry > Configuration > Accounting > Rules
The first step is to set up the your Accounting Book. To do this, navigate to:
126
Notes:
The Accounting Link field in the Accounting Rule Book Link Tab is used to link a specific
Accounting Book to an Accounting Rule. The significance of the Accounting Book mentioned
in the Accounting Link field is that the Accounting Book mentioned in this section, allows
Calypso to apply accounting strategies to an institutions ‘portfolio’ of trades by associating an
Accounting Book to a particular or several Trading Books.
With the above in mind, if we review our two trades (Equity and Swap) booked earlier, we now
understand how the Accounting Engine would have found the correct Accounting Rule for these
trades.
When the PSEventTrade was published by the Event Server, the Accounting Engine would have
filtered all the Accounting Rules in the system and found (so far) the correct Accounting Rule to use
based on the Accounting Book CALYPSO UNI BANK which is linked to the originating Trading Book
in which the two trades were booked.
• Set the product. The Product Type field in the Accounting Rule ‘Book link’ tab is used to
determine if a particular Accounting Rule should be applied on ‘All’ products or a specific product
For our case scenarios, we have defined that for the same Accounting Link (Accounting
Book) our two products (Equity and Swap) use different Accounting Rules.
127
Notes:
With the above case, the Accounting Engine, when receiving the PSEventTrade (from the Equity
and/or Swap trades booked), would have filtered all the Accounting Rules in the system and found the
corresponding Accounting Book (CALYPSO UNI BANK) linked to the Trading Books. It would have
found that the Accounting Book has been linked to two Accounting Rules.
To decipher the correct rule to apply against the correct PSEventTrade, the Accounting Engine will
refine further its search. Based on the product type indicated in the ‘Product Type,’ the Accounting
Engine will determine the correct rule to associate for the relevant PSEventTrade.
• Set the Static Data Filters (if any). Should users want to define additional criteria for when a
particular Accounting Rule should be applicable, then the SD Filters field in the Accounting Rule
‘Book link’ tab allows users to assign filters to an Accounting Rule
Once the system has found the correct Accounting Rule to apply, in our case
‘SWAPTRADING’ for the Swap and ‘Equity Trading’ for the Equity, the engine will:
• Review the Accounting Events within those rules to determine if they are applicable for the Event
in question
• For the relevant Accounting rule/Accounting Event, it begins to generate its output (postings)
affecting the specified + - accounts (defined in the rules)
Accounting Events and Accounts are attached to an Accounting Rule via the Configurations tab.
Refer to the Accounting Events and Accounts sections below to configure these before linking them to
an Accounting Rule.
Accounting Events
As mentioned above, in order for the Accounting Engine to review the Accounting Events linked to a
particular Accounting Rule, you would first have had to configure/define Accounting Events. Once you
have defined Accounting Events, you can then link them to an Accounting Rule.
Accounting Events are triggered by various business related events or actions. These could be
related to events from trades, exercises, settlements, amortizations, accruals, margin calls, corporate
actions, liquidations, etc. Another example would be, when actions (like exercises, valuations,
128
Notes:
expiries, resets) take place or transactions (like terminations, liquidations) occur during the lifecycle of
a trade. These would all trigger Accounting Events.
In our case, the event that occurred and instigated the generation of the accounting entries was a
trade related event. When our trades (Equity and Swap) were booked and saved in the system we
had seen that the effect of the trades reaching a specific status triggered certain Accounting Event.
Accounting Events
generated when Swap
trade was saved.
Accounting Events generated when

Equity trade was saved. Whether
the Event Types generated is COT
(off balance) or NOM_FULL. This is
at the discretion of the
organization.
To configure an Accounting Event, navigate to:
Main Entry > Configuration > Accounting > Events
129
Notes:
Left panel of the

window allows you
to view the saved
Accounting Events
in a tree fashion. The Right panel of
Accounting Events the window allows
can be configured you to view the
for ALL Product saved Accounting
Types or by Events in a table
Middle section fashion as saved in
specific Product.
determines the the database.
Double click on the
behavior of a
positive sign to see
particular
drill down of Events
Accounting
on Product Type.
Event.
Calypso determines Accounting Events by Product Types. You either need to have an Accounting
Event configured with category Product type of 'ALL' or define an Accounting Event for specific
products.
Fast-Track is preconfigured with some general Accounting Events and reviewing the left or right
panels will show you what events are available out-of-the-box. Should you not find the saved
Accounting Events sufficient and need to configure or modify some according to your business needs
and the products that you are using, this is also possible. Calypso University Accounting course covers
this in detail as does the Calypso documentation.
Below, we will review the most important and relevant fields for this course that are pertinent for the
generation of an Event.
1
1
2
1
1. Using the Accounting Event Type dropdown, determine the relevant Accounting Event
(business related event or action) you require to be generated
In the example above, the Accounting Event selected is ‘COT.’ This is the Calypso
acronym for ‘contingent liability.’ This is to signify the amount that would be due in the
future depending on future events.
2. Select the Product for which this particular Accounting Event will be used for via the Product
drop down. In the example above, we have indicated the Accounting event COT should apply to
Equity products
130
Notes:
3. The eclipse next to Trigger Events allows users to define the business related events/ actions
for which, when they occur, the Accounting Engine will retrieve the relevant Accounting Event
type and generate that particular Accounting Event for the product type
If the Accounting Event you need

requires measures, you can use
this eclipse to add them.
The main purpose of a Pricer

3
1 Measure is to allow you to
extend or override the way
valuation events (example;
MTM/Accrual, etc.) is computed
within the system.
4
4. Having defined all of the above steps, you will need to ‘Save’ your configuration
To determine the behaviour/functionality of an event, users will need to configure the other
fields within the Accounting Event Configuration based on their business requirement.
• Retro activity: circumstances under which a past posting is modified,
• Booking Type: if modified and inventory related how modification is calculated,
• Event Class: in which category the event is aggregated/categorised
• Event Property; if it event is transfer/payment related or not and if so what type) do not
come into play.
Calypso University Accounting course covers this in detail as does the Calypso documentation.
Accounts
As the Accounting Engine generates and saves each posting, it designates each posting to a
particular account/account number. Accounts are entities in Calypso where the Accounting Engine
applies debit or credit to postings. These postings represent a bank’s chart of accounts and are
generated with the purpose of being fed into the bank’s General Ledger system. These accounts are
linked with Accounting Events via the Accounting Rule.
Accounts, like Accounting Events need to be configured/define before they become accessible for use
in the Accounting Rule.
To configure an Account, navigate to:
131
Notes:
Main Entry > Configuration > Accounting > Accounts

By default, the account definition window opens up on the 'Account' tab. Via this tab, applying the
'New' button will give user a clean Account definition screen allowing the possibility to create the
relevant accounts desired according to the business need/case. Once having done so, the account
needs to be saved.
Below we will review the fields that are pertinent for our example. Accounts are covered in greater
detail in the Fundamentals of Calypso Accoutning course and the Calypso documentation.
1
1
3
2 1
1. The Account Name field is a free format field that allows users to input an Account Name. This is
generally linked to the business activity you are going to be using the account for. For example:
naming an account ‘CUB NOSTRO Account’ would suggest that the account would be used to
represent a NOSTRO account
2. The Processing Org drop down allows the possibility to designate the Processing Organization
that the account belongs to
3. The Ccy drop down determines the eligible Ccy the account caters for
4
1
4. The Account Type allows your organization to categorize your accounts into their various use
functions. Type, determines what kind of account it is
For example, this could be asset/liability/receivable etc. type of account that would be either
credited and/or debited when a transaction occurs. By default, within Core Calypso there are
132
Notes:
several types of Accounts that can be used according to the business requirements of your
financial Institution. To define a ‘Type’ for an account, use the dropdown next to the type field.
If you do not find the Account Type you are looking for, the ellipses button next to the 'Type' drop
down allows you to open the Additional Account Type window and add/remove any other types of
Accounts that may be necessary for your institution/business purpose. (Note that the code behind the
custom account Type must already exist for Calypso to determine associated actions to apply to it).
From a Back Office perspective, one of the most important account types is the Account type
SETTLE. This is because, the account type SETTLE records/accounts for the actual movement
(transfer) of cash and/or security of the Processing Organization.
5. Using the Legal Entity and Role fields, you can determine the agent/customer by whom or for
whom the account is held. These are only required should the account type be SETTLE
The SETTLE account type is restricted to a specific Processing Organization and currency.
This account type can be used to represent either:
The account of the Processing Organization held at its NOSTRO, Custodian agent where
from whom or to whom cash and/or security are held and will move. This is in which case the
Legal Entity mentioned on the account needs to be the Agent holding the account and the
role needs to be ‘Agent.’
5a
OR:
A client’s (or counterparty’s) account held at the Processing Organization where cash and/or
security are held and will move to or from. In which case the Legal Entity mentioned on the
account needs to be the client (or counterparty) holding the account and the role needs to be
‘Client’ or ‘Counterparty’
5b
133
Notes:
Because these accounts represent cash and/or security movements, Calypso links them on the
settlement instructions (refer to screenshot below and also section on Settlement Delivery
Instruction), thus to BOTransfer Object.
Should you have a SETTLE account at a particular Agent or for a particular client across different
currencies, rather than manually saving an Account per Currency each time there is a transaction in the new
Currency that needs to be settled, Calypso allows you to generate the relevant accounts automatically as
soon as you have movements in those currencies providing you have defined relevant attributes for
generating the automatic accounts. You would need to flag account as ‘Auto/Template ACC,’ select Ccy as
‘AUTO’ and define the characteristics of automation via the Attributes tab. Refer to section on automatic
accounts below for further details.
Accounting Rules, Accounting Events & Accounts

Once Accounting Events and Accounts are defined, they can be linked to an Accounting Rule (via the
Configuration tab), which specifies to the system the accounts to be debited and credited when a
specific Event occurs.
Calypso supports a
double-entry booking
system, thus every
accounting event
effects/changes two
different accounts.
Now that we have the necessary setup and taking our trades as an example, let’s review how the
system functions taking two scenarios (trade related and transfer related) as an example.
134
Notes:
For a trade related scenario, when our Equity trade and/or Swap trade was saved, the event server
published a PSEventTrade respectively for each trade. The Accounting Engine, having subscribed to
this event, received the event. The Accounting Engine filtered through all the Accounting Rules in the
system and found the corresponding Accounting Book (CALYPSO UNI BANK) linked to the Trading
Books OTC Trading Book and Equity Trading Book.
We had mentioned that two Accounting Rules would have been found for the same Accounting Book
CALYPSO UNI BANK. After further filtering (Product Type/Static Data filter mentioned above), the
Accounting Engine would have found an Accounting Rule which corresponded to the correct
Accounting Book/Product Type combination. For each Accounting Rule found, SWAPTRADING and
Equity Trading, the Accounting Engine would review the list of Accounting Events within the rules
(configuration tab) and begins to determine, for the Accounting Events found, which Accounting
Events are applicable.
The way in which the Accounting Engine determines the Accounting Events applicable is by reviewing
(for the Accounting Events found in the Accounting Rule) if an Accounting Event configuration for the
product type in question exists and if so, do the trigger events on the Accounting Events comply.
For example, on our COT Accounting Event for our Equity Case, the trigger events were
CANCELED_TRADE/TERMINATED_TRADE or VERIFIED_TRADE. Checking the status of the trade
that instigated the PSEventTrade, the Engine would have deemed that the status on trade to be
VERIFIED, thus complying with one of the trigger events listed on the COT.
As a result, for the relevant Accounting rule/Accounting Event, the Accounting Engine begins to
generate its output creating BOPosting Objects (postings), which credit and/or debit specified
accounts (defined in the rules). These postings will then be fed into the bank larger GL system.
Trade
generates
TradePosting
BOPosting
135
Notes:
By now, we know and understand that when our Equity trade and/or Swap trade was saved, the
BOProductHandler created all the transfers related to those trades by using the cash or security
flows. We explained that provided Settlement Instructions are in place, Calypso links each transfer
(BOTransfer object) with the correct delivery instructions by using Trade Transfer Rules. Each
BOTransfer object, when created in Calypso, contains all the information needed (from a Back Office
perspective) to process the cash flow or security movements.
One of these processes is the accountability of cash/security movements to and from
Nostro/Custodian or Client/Counterparty Accounts. This is done by generating accounting entries that
represent these movements in the system.
To initiate this process, instead of the Accounting Engine subscribing to the PSEventTrade, the
Accounting Engine needs to subscribe to the PSEventTransfer.
Select the event ‘PSEventTransfer’ in the Event Class

and assign the Accounting engine as a Consumer in
the consumer field.
Use the ‘Add’ button to ensure your selection is

taken into account before saving your configuration
using the ‘Save’ button.
Why PSEventTransfer? We will come back to this at a later section, but at this point, it suffices to
know that a trade creates a transfer that follows a lifecycle known in Calypso as a Transfer Workflow
(we will address workflows in the workflow section), and when the BOTransfer reaches a particular
workflow status, the Event Server publishes a PSEventTransfer.
When the Event Server publishes a PSEventTransfer (which is derived from a BOTransfer object
reaching a status), the subscribed Accounting Engine receives the event. This means the Accounting
Engine would go through the same procedure as the trade scenario, filtering through all the
Accounting Rules in the system to find the corresponding Accounting Book (CALYPSO UNI BANK)
linked to the Trading Books (OTC Trading Book and Equity Trading Book) associated with the
originating BOTransfer object.
136
Notes:
Again, two Accounting Rules would have been found for the same Accounting Book CALYPSO UNI
BANK and it would continue to filter the configured rules to find the rule that corresponds to the
correct Product/Static Data of the BOTransfer object. For each Accounting Rule found,
SWAPTRADING and Equity Trading, the Accounting Engine would review the list of Accounting
Events within the rules (Configuration Tab) and begins to determine, for the Accounting Events found,
which Accounting Events are applicable.
As part of the Accounting Rule configuration for cash payment transfer related events (so in our case
our Swap transfers), the Accounting Engine would have presumably found the Accounting Event
‘CST’ or its derivative which would be CST_ <value>.
137
Notes:
For Settle accounts,

users only need to
define the type as
‘SETTLE.’
According to the
related/underlying
BOTransfer object,
the system is able to
find the correct settle
account to
debit/credit.
For security payment transfers, which in our case would be the Equity, the Accounting Event would be
SEC_SETTLED (or SEC_FAILED).
We had mentioned earlier that the Account Type SETTLE was important from a Back Office
perspective and we will review the reason here. Accounting Events such as CST and SEC_SETTLE
would normally be setup to credit or debit the Account Type ‘SETTLE.’ The account type SETTLE is
138
Notes:
important as it used to record (in terms of Accounting) the actual movement (transfer –
payment/receipt) of cash and/or security of the processing organization.
You will notice, for these account types, the name of the account to debit or credit is not listed as part
of the accounting rule configuration. This is because Calypso is able to retrieve the correct SETTLE
account (listed as the GL A/C within the SDI configuration window) for the Accounting Event
representing the cash or security movement to and from Nostro/Custodian or Client/Counterparty
Accounts by using the BOTransfer object which has all the information from the Settlement
Instructions.
Should the Accounting Engine find either of these (CST or SEC_SETTLED in our case) as part of a
rule, it would review the trigger events of these Accounting Events to verify if the BOTransfer object
complies.
BOTransfer BOTransfer
Object Object
workflow. workflow.
Status. Status.
For both the CST and SEC_SETTLED events, the BOTranfer Object would comply only when the
BOTransfer object is in one of the workflow statuses sited in the respective Trigger Event section. Our
screenshot shows that one of the statuses mentioned as a Trigger Event for the CST is
SETTLED_PAYMENT, and according to our setup, when our cash transfer is settled the Accounting
Engine will generate a CST accounting entry.
One of the Triggers on CST

Accounting Event is
SETTLED_PAYMENT
The SEC_SETTLED event will be generated when our Equity BOTransfer security is settled.
139
Notes:
One of the Triggers on

SEC_SETTLED Accounting
Event is
SETTLED_SEC_RECEIPT
Refer to the section on Workflow to review how transfers arrive to ‘SETTLED.’
Trade
generates
generates
BOPosting BOTransfer
TransferPosting
140
Notes:
Although in the above example, we covered the accounting entry generation derived from PSEventTrade
and PSEventTransfer, it is important to note that accounting entries can be instigated by other PSEvents such as:
• PSEventLiquidatedPosition
• PSEventUnliquidatedPosition
• PSEventPriceFixing
• PSEventRateReset
• PSEventFXRateReset
• PSEventProcessTrade
• PSEventHedgeValuation
• PSEventProcessTransfer
• PSEventValuation
• PSEventPositionValuation
• PSEventFXPositonValution
• PSEventPositionRecalssification
• PSEventBalanceReclassification
For each of the PSEvents listed the general logic of accounting entry generation remains constant. Provided the
Accounting Engine subscribes to any of these events, it will receive information from the Event Server when the
event occurs. Thereafter, the filtering of Accounting Rules begins and the Accounting Engine once it has found
the corresponding rule will review the Accounting Events attached to the rule to determine if event complies with
the trigger events listed as part of the particular Accounting Event before generating an entry.
141
Notes:
Module 6: Workflow -
Lifecycle of Components

• Explain the principles and use of Workflow
• Configure a Workflow
• Explain how to achieve Straight-Through-Processing (STP)
• Explain the purpose of Tasks and Rules
• Explain use of Kick-off / Cut-off timers
• Explain the Four-Eye Principle

MODULE 6 Workflow – Lifecycle of Components
Introduction
In our previous modules, we used a trade transaction to explain that at the origin of the different back
office components is a Trade. In this module, we will be moving forward with the lifecycle concept and
how Calypso uses it.
Trades create messages as they move through the system. The workflow helps establish where a
trade or transfer is in the system and what should happen to it next. When actions are applied, the
workflow also sets a path for it to travel through. Business need dictates how the workflow can be set,
and this module will primarily touch on scenarios that describe on how the workflow can be configured
and its eventual behavior.
Certain trade types can be anticipated by the system, meaning that they mean certain criteria, and
can be pushed through the system using straight-though-processing, or STP. This module will cover
the windows used to configure a workflow and modify workflows that Calypso provides out-of-the-box.
143
Notes:
6.1 Overview of the Calypso Workflow Process

In financial markets, the ability to manage the flow of business (trade lifecycle,
confirmation/reconciliation and eventually payment/settlement) with as little human interaction as
possible is referred to as Straight-Through-Processing (STP). The way in which STP is implemented
and applied in a financial institution is solely at their discretion and is dictated by institutional flow of
business and available infrastructure.
Calypso provides a flexible workflow solution that allows institutions to manage and automate their
Back Office operations by defining STP. The Workflow functionality in Calypso allows for high level of
visibility and control over the operation of a financial institution’s processing department.
In previous modules, we explained how objects are used in the system. Now that you understand
objects, we can move further to show how Calypso uses the Workflow Solution to manage the
lifecycle of an object: a trade Object follows a trade Workflow, BOMessage object follows a message
Workflow and BOTransfer object follows a transfer Workflow, etc. The out-of-the-box Workflow
management system allows for the individual lifecycle management of trades, transfers and
messages at the Processing Organization’s Product Type level.
As the Workflow is required to carry out a majority of Calypso’s Back Office activities, it is often
considered to be the backbone of Calypso Back Office solution (the section on ‘General logic’ below
discusses the implications of Workflow for Back Office output). The idea behind Workflow is to
streamline Back Office Operations were users can only intervene in the case of an exception, such as
an error or a special case.
In our previous modules, we had mentioned Postings as part of the components of a Trade. It
should be noted that, although Postings can be generated as a result of the lifecycle of trades &
transfers, Calypso does not manage the Postings lifecycle via the Workflow.
Preliminary Configuration
Unlike the engine configurations or subscriptions required for generation of transfers, messages and
postings, the Workflow (apart for the transaction of a particular functionality which we will discuss
later) does not have an engine per se, nor does it need to subscribe to any PSEvent.
What is required is that it is activated, and activation is done in Calypso by default. This means the
Workflow is permanently activated (screenshot below) and managed by the Data Server.
To review activation, navigate to:
Main Entry > Utilities > Maintenance > Monitoring > Admin Monitor
144
Notes:
Workflow cannot be deactivated. Activation ensures that trades, transfers, messages and postings
begin their lifecycle.
145
Notes:
6.2 General Principles of Workflow

Workflow Concept
As trades, payments and messages move from creation to completion, they advance through a series
of lifecycle states known as statuses in the system. Each stage has a status code, such as
‘PENDING’ or ‘VERIFIED.’
A user in the operations department can advance an item from one stage to the next, or the system
can be configured to advance the item to the next stage automatically. This advancement from one
stage (status) to the next is what is considered as the ‘’Workflow.’
When a trade is saved, a payment and a message are generated in Calypso’s Workflow system and
immediately create tasks. Tasks, however, are not limited to these three objects.
Calypso’s Workflow system also saves tasks for various other events that occur, such as edited data
(a rate reset on a BOTransfer) or errors (Legal Entity contact information missing on a trade) as long
as they are specified in the Workflow.
The Workflow can be configured to perform tasks automatically (through STP), in real time, as long as
certain conditions are met, Users can stipulate that certain tasks must be performed manually,
requiring user interaction/manual resolution. In this case, the tasks represent an Exception. For each
task that moves down the Workflow lifecycle, users and applications are actually managing the
lifecycle of the objects. The way they manage the lifecycle of the objects is by the tasks.
A task is any issue or step in Calypso Back Office operations that is sent to a user or an application
for resolution or completion and will move objects from one status to the next. The status represents a
point in the object lifecycle and from where the object waits for something to happen. For something
to happen, a task needs to be resolved or completed. A rule defines the condition for the object to go
from one status to another. Should conditions of the rules defined not be met, Calypso would treat
them in a specific way.
In order for users to complete a task, actions must be carried out on a task. An action is anything that
a user does to a trade, payment, message, such as amending, cancelling, sending or any other event
(rate reset/liquidation, etc.). The action can be based on actions carried out by users or by the
system. An object requires an action (a Workflow Step) to go from one status to the next. For
example, the steps ‘PENDING > AUTHORIZE > VERIFIED’ describe the action ‘AUTHORIZE’ which
will move an item from ‘PENDING’ status to ‘VERIFIED’ status.
The list of available actions for a task specify all the transitions that can be carried out for back office
activity and depends entirely on the Workflow configuration. Each status is linked by at least to one
action (step) and there could be several possible actions (steps) for each status.
Calypso provides an out-of-the box Workflow configuration, however, users can add or remove as
many statuses as desired in order to suit business need. It is important to note that some statuses
(NONE and CANCELLED) are mandatory and reserved for Calypso. They should not be deleted or
modified.
Calypso requires that all Workflows start from the status NONE and apply the action NEW, thereafter,
other statuses and actions (again with the exception of CANCELED status) can be arranged and
modified as seen fit. Additional tasks can be added. Additionally, to apply the Straight-Through-
Processing logic, users can specify rules that must be met for transitions to be successful.
If a rule is broken, it will stop the object from moving down the Workflow (keeping it in its previous
status), and it will trigger where possible, exceptions. These identify the conditions not met and allow
users and system to insert comments defining the issue of a break.
146
Notes:
Engines, Events & Workflow

Before we discuss configuration of the Workflow lifecycle, it would probably be helpful to take a step
back to get a better view of the general Back Office concept in Calypso. We know that for back office
purposes (management of cash & security flows, settlement, maintenance of total held positions,
generation of messages & accounting), at any given moment Calypso would have a number of
Engines can be running. We had given a list of these Engines in the introduction module. These
Engines react to the various events that occur in the system.
For example:
Transfer Engine: Responsible for generating Transfers (cash/security), and reacts to Trade,
Rate resets and Liquidation events.
Message Engine: Responsible for generating Messages (advices, confirms, payment / receipt
Instructions) and reacts to (amongst others) Trade, Rate resets, Rate fixings,
Transfers (payments/receipts) events.
Accounting Engine: Responsible for generating accounting entries and reacts to Trade, Transfer
(payments/receipts) and valuations (trade/position) events.
Liquidation Engine: Responsible for tracking and updating position of instruments of each trading
book reacts to Trade events.
Inventory Engine: Responsible for tracking the amount of a given security or currency that an
organization owns at a specific agent and reacts to transfer (cash/security)
events.
So, keeping in mind the listed Engines mentioned above and their reaction to events, to explain how
the Workflow comes into play, let’s look at a case where a Trade (we will use a Swap) is saved, the
rate reset is updated and the transfer associated to a given flow of that trade is settled.
To generate the required back office outputs associated with these events, Calypso uses the Engine
Event subscription logic (providing correct configuration for the particular object exists) and Workflow
to bring to life an object either from scratch or using the Workflow to create new events (a
confirmation, a payment, a posting, a position, etc.) from an existing object.
The breakdown of our Swap example would be something like this:
• Trade being saved (PSEventTrade) and in ‘X’ status triggered
• Transfer Engine è to generate NEW transfers (BOTransfer Object) for cashflows associated with
Swap
• Message Engine è to generate NEW message (BOMessage Object) as confirmation of trade,

only if the Message Configuration corresponds to ‘X’ status of the object
• Accounting Engine è to generate NEW accounting entries (BOPosting Object) to represent

transacted amounts, only if the Accounting Event Configuration corresponds to the relevant ‘X’
status of the object
• Liquidation Engine è uses Product id information from Trade Object to UPDATE a trading book’s
position held on an instrument
Rate reset updated (PSEventRateReset) would trigger:

• Transfer Engine è to UPDATE floating leg cash transfer (on EXISTING BOTransfer Object)
147
Notes:
• Message Engine è to generate NEW rate reset message (BOMessage Object using EXISTING
BOTransfer Object that got reset), only if the Message Configuration corresponds to ‘Rate Reset’
event that occurred on existing Object
Transfer ‘SETTLED’ (PSEventTransfer) would trigger:
• Message Engine è to generate new payment/receipt message (BOMessage Object from an

existing BOTransfer Object that becomes settled), only if the Message Configuration corresponds
to relevant Event that occurred, thus settlement ‘SETTLED’ of the object
• Accounting Engine è to generate NEW accounting entries such as CST (BOPosting Object from
the EXISTING BOTransfer Object that has settled), only if Accounting Event Configuration
corresponds to relevant Event that occurred, thus settlement ‘SETTLED’ of the object
• Inventory Engine è to update cash/security position held at agent (using existing BOTransfer
Object that has become SETTLED)
For the behavior described above:

NEW: Calypso generates the necessary Back Office relevant objects mentioned using both
the logic of Engines subscribing to the event in question and the Workflow. The
Workflow is used to start the new objects on ‘their’ lifecycle track.
EXISTING: Calypso generates a new object using both the logic of Engines subscribing to the
events and the Workflow (which uses existing objects and the Event points in the
workflow, to create new objects).
UPDATE: Calypso updates objects and positions (Liquidation/Inventory) using either new or
existing objects which got generated using the logic of Engines subscribing to events
and the Workflow.
When an object is created using an existing one, the point in which the new object starts its own
lifecycle track can depend on where the initiating object is in its own lifecycle which is user
configurable.
For example, we mentioned that the Transfer (PSEventTransfer) was SETTLED, and when SETTLED
created Messages/Accounting, etc. This can also be done (Message/Accounting, etc.) when the
Transfer reaches the status ‘VERIFIED’ or ‘XYZ’ for that matter. As long as Message configuration or
Accounting Event configuration corresponds, the Engines will generate the required output.
Actions vs. Events

In our Swap example, the Actions and Events created outcomes. Actions and Events should be
clearly distinguished.
Actions are carried out by users or applications, and are usually related to a trade, payment or
message. Thus, ‘creating our swap trade’ was an action. Events are messages sent by Calypso
applications to notify other parts of the system that something has occurred.
Most Events (but not all) are triggered by Actions, and an Event that corresponds to an Action will
generally have the same name as the Action. So, loosely, it could be viewed that an Action is the
cause and Event is the effect.
148
Notes:
Trade Lifecycle
The action of creating a trade in Calypso makes it ‘Workflow’ compliant and thus marks the beginning
of its lifecycle. As the trade advances from creation to completion, it moves through a series of
lifecycle stages.
Examples of these stages are PRICING, PENDING, VERIFIED, CANCELED, MATURED, and
TERMINATED. The stages a trade passes through are dependent on the lifecycle of a particular
asset class. For example, the lifecycle of Equity would not have exactly the same stages as OTC.
The starting point of a Trade lifecycle in Calypso is represented by the transition NONE - NEW - <any
status> (this is a must). Where the <any status> could be NONE – NEW – ABC/XYZ/MYSTATUS or
any user-defined term. Each stage a Trade moves though in Calypso is referred to as a status. The
set of possible statuses that a Trade may transition between is referred to as its ‘Workflow’.
Three Engines in Calypso handle a trade based on its Trade Lifecycle status:
• Message Engine (where we showed how the message configuration is dependent on trade status)
• Accounting Engine (where we had shown accounting events can be dependent on trade status)
• Task Engine (which we will cover later)
Trade Retrieval
The workflow retrieval process in Calypso uses two parameters to find the correct Workflow to apply:
• The Processing Organization (so if PSEventTrade workflow, the PO attached to Trade)
• The Product Type
Calypso searches first for a specific Processing Organization set on the trade. For the Processing
Organization, it searches for a specific Product If the specific Processing Organization is not found,
then Calypso will search under the Processing Organization ‘ALL’ domain. If the specific Product
Type for the specific Processing Organization is found, then it is used. If it does not find the specific
Product, it searches for Product ‘ALL’ under the specific Processing Organization.
For example, if we have a workflow for a specific Processing Organization ‘CUB’ and Product ‘ALL.’
We also have another workflow configured for Processing Organization ‘ALL’ and Product
‘EQUITY.’ Calypso will take the workflow for the specific Processing Organization ‘CUB’ and Product
‘ALL’ first.
The following flow chart helps to explain the sequence of workflow selection:
149
Notes:
START
Is there a PO NO
Select PO ALL
specific workflow? Workflow
YES
Select PO
Specific
Workflow
Is there a Product NO
Select Product
specific workflow? ALL Workflow
YES
Select Product
Specific END
Workflow
Transfer Lifecycle
As was already reviewed, transfers are generated by the Transfer Engine for any movement of cash
and/or security attached to a trade. Along with the Engine Event Subscription and the
Cashflows/Security flows, a BOTransfer cannot be generated without a configured Transfer Workflow
When a BOTransfer is generated, it follows its own (lifecycle) Workflow starting at NONE - NEW -
<any status>. This will move the BOTransfer object (cash or security) through its own lifecycle
determining the actual settlement, cancellations, amendments, etc. The transfer Workflow is
configured by Processing Organization, Product Type, and transfer type.
150
Notes:
Transfers are recognized as ‘Settled’ in Calypso once they have been verified. Transfers are
verified when the amounts are known, i.e., there is no outstanding resets to be applied.
Transfer Retrieval
When looking for the available Workflow transitions, two parameters are used, the Product Type and
the Processing Organization attached to the transfer. The process is similar to the Trade workflow
retrieval. Calypso searches first for a specific Processing Organization attached to the transfer and if
none is located, it searches under ‘ALL.’
Message Lifecycle
A message identifies any document or payment that you send or receive to/from an organization
(including contacts within an organization) to alert them of an event that has occurred on a trade,
payment, position, etc. In previous modules, (Generation and Breakdown of Component) a Trade
message example presented the steps that were required to generate a message.
For the Trade and payment message, we had reviewed the process of how the Message Engine
generates messages based on:
• Engine event Subscription (in this case Message Engine’s subscription to Trade Event)
• Relevant Message configuration
• Correct contact information
When the BOMessage is generated, it follows its own (lifecycle) Workflow. A BOMessage Object is
not able to be generated without the existence of a message Workflow, where the mere action of
creating a message is represented by the transition NONE - NEW - <any status>.
It is clear that in the case of the payment message, at ANY point of the Transfer Workflow, a payment
message can be generated and the message Workflow takes care of it from there. Although the
BOMessage is a preview version of what will later be sent to the recipient, it has for all intents and
purposes become alive.
Message Retrieval
When Calypso looks for the available Workflow transitions, three parameters are used, the Product
Type, the Procession Organization and the Message Type attached to the Message Object. The
process is similar to the Trade and Transfer workflow retrieval.
Calypso first searches for a specific Processing Organization (attached to the transfer). For the
Processing Organization, it searches for a Specific Product (again attached to transfer).
If it finds the specific Product Type for the specific Processing Organization, then it uses that. If it does
not find the specific Product, it searches for Product ‘ALL’ under the specific Processing Organization.
151
Notes:
If however they system does not find a Specific Processing Organization, then Calypso begins to
search under the Processing Organization ‘ALL. In the event there is a subtype, the priority is after
Processing Organization, but before ‘Product.’
For example, for a message CONFIRM Equity, the specific subtype ‘CONFIRM’ is before the specific
product EQUITY.
The following flow chart helps to explain the sequence of workflow selection:
START
Is there a PO NO
Select PO ALL
specific workflow? Workflow
YES
Select PO
Specific
Workflow
Is there a Subtype NO
Select Subtype
specific workflow? ALL Workflow
Select Subtype Select Product

Is there a Product
Specific YES Specific
specific workflow?
Workflow Workflow
NO
Select Product
END
ALL Workflow
152
Notes:
6.3 Workflow Configuration

Definition
Calypso provides two different windows to define your desired Workflow Steps that move an item
from one status to another. Users can use the ‘Workflow Config Window’ and/or the ‘Workflow Graph
Window’. Regardless of which window is used or any Workflow transaction configuration, the below
fundamental features need to be configured.
1
2
1. Processing Org: A Processing Organization to which the Workflow transition is applicable

needs to be defined.
This can be ‘ALL’ (in which case it will be applied to all Processing Organizations)
OR:
a specific Processing Organization. In our case we have defined one for our Processing
Organization ‘CUB.’
2. Event Class: the object for which the Workflow needs to be identified.
An example of this would be:
PSEventMessage - Message Workflow
PSEventTrade - Trade Workflow
PSEventTransfer - Transfer Workflow
3. Subtype: The object can have subtypes defined. The available subtype depends on the object
type. This allows for advanced specification of the objects lifecycle. A subtype could be either set
to ‘ALL’
For our example of messages generated for our Equity trade, this could be subtype
CONFIRM or the subtype RECEIPTMSG (or PAYMENT_ADVICE and PAYMENTMSG
for our Swap example).
Transfer Workflow: this specifies whether the transfer is NETTED or unnetted. NETTED would
identify transfers that have been grouped together by user defined characteristics.
153
Notes:
Trade Workflow: this specifies a number of subtypes based on the order:
• The trade attributes (keywords)
• A static data filter
A product subtype (only available once you have selected a Product Type)
Product: this is the Product Type for which the Workflow needs to be identified. This could be set to
either ‘ALL’ or set to a specific Product Types.
You can also set up a Workflow to apply to a Product Group. The Workflow will apply to all the
products listed within this product group.
Accessing Existing Workflows

If you would like to access an existing workflow, follow the below steps.
Using the Workflow Graph Window, navigate to:
Main Entry > Configuration > Workflow > Workflow Graph
154
Notes:
From the top left of the Workflow graph window, access the ‘View’ menu and:
1. Select will allow you to select all the criteria that identify a Workflow. Determine the Event class
type you are searching using the ‘Select Event Class’ window
2. Using the ‘Select Processing Org’ window select the processing organization for which you
are searching a workflow
3. Using the ‘Select Product’ select the product for which you are searching a workflow for
155
Notes:
1 2 3
If a Workflow already exists in the system for the selected criteria, it will appear in the right hand side
of the graph window as per the below screenshot.
156
Notes:
From the tree branch on the left hand side of the Workflow Graph window:
1. Choose the relevant Event class
2. Choose the relevant Processing Organization (this could be ‘ALL’)
3. Choose the relevant Product (this could be ‘ALL’)
4. Choose the relevant Subtype (this could be ‘ALL’)
1.
2.
3.
4.
If a Workflow is present, you will see it in the graph on the right hand side of the window.
To zoom in and out of the Workflow use the "+" and "-" magnifying glass icons.
If using the Workflow Config Window, navigate to:
Main Entry > Configuration > Workflow > Workflow
157
Notes:
Using the left pane tree branch of the Workflow graph window:
1. Choose the relevant Event class
2. Choose the relevant Processing Organization (this could be ‘ALL’)
3. Choose the relevant Product (this could be ‘ALL’)
4. Choose the relevant Subtype (this could be ‘ALL’)
2
3
4
As per the screenshot below, the right pane of the Workflow Config window will update the table to
show you the existing configuration for your selected choice.
158
Notes:
Creating Workflow Statuses & Actions using Graph Method

Using the Workflow Graph window via the icons from the toolbar, you can create your desired
Workflow transitions for different components (trade, transfer, and/or messages).
To create a Status:
1. Highlight the icon

2. After highlighting the icon, move the curser to the graph on the right side of the pane
The system will automatically open a ‘New Status’ window (such as below)
159
Notes:
You can select a status

3
rom the dropdown in the New
Status window.
In order for a status to be viable and for Calypso to save it, it will need to be associated with an action.
To link an Action to your Status:
1. Highlight this action icon

2. Select a status
3. Drag the mouse to another status (assuming you have created another one)
4. Drop the mouse when you reach the next status
The Workflow Action window will appear so that you can define the action between the two statuses.
160
Notes:
A Complete Workflow transaction configuration will

require that some aspects of the four portions of the
Workflow Action window (divided in window on the
right) be defined.
While the icon is still activated, you can add another action by selecting any status from the graph and
double click it to open the Workflow action widow.
161
Notes:
Modify/Adjust & Delete Workflow Actions & Statuses with Graph Method
To modify/ delete existing actions when the icon is highlighted (activated) you can:
• Double-click an existing action and when the Workflow Action window opens you can
modify/delete an action
• Right click on an action. This will allow you to rename it, remove it and define other
characteristics (kick-off/cut-off configuration) or check if it is used in any trade/message/transfer
task
Properties option
opens up the
Workflow action
window from which
any of these
workflow options
can be conducted.
Menu Items D
To modify/adjust/delete existing Statuses when the icon is highlighted (activated) you can:
• Right click a status and rename it, remove it, and check if the status is used in any
trade/message/transfer task
162
Notes:
You cannot remove a status if there is an action attached to it.
• To move statuses and actions around the graph and to adjust layout, when the icon is
highlighted (activated)
• Drag and drop the cursor on the status or action and move them around
Duplicate Workflow using the Graph Method

Rather than creating a new Workflow, you can duplicate a Workflow for any Event Class.
Assuming you would like to duplicate a Transfer Workflow of a particular Processing Organization,
follow these steps:
1. At the bottom right of the Workflow graph, click the ‘Duplicate’ button.
163
Notes:
You can also use the menu File > Duplicate on the top left-hand of the Workflow Graph
Window to access this functionality.
2. Select the type of Workflow you wish to duplicate in the ‘Duplicate What’ pop up window and
click ‘OK’
3. Select the source Processing Org in the ‘Workflow Source Window’ and click ‘OK’
4. Select the destination Processing Org in the ‘Workflow Copy To’ window and click ‘OK’
164
Notes:
5. The ‘Workflow Event Class to Copy’ window will pop up. Select the Workflow type to copy
represented by the Workflow Event Class and click ‘OK’
Creating Workflow Using Tabular Configuration

The workflow window can be used to create workflows form scratch. All of the elements needed to set
up a workflow exist within the window, and a user can trace which transitions have been added in a
table on the bottom part of the window.
To save a new Workflow Configuration:
165
Notes:
1. Click ‘New’ for a new configuration window

2. Define the various fields on the top half of the window for the new Workflow
3. Click ‘Save’
2 A Complete
Workflow
transaction
configuration will
require that some
aspects of the
Workflow Config
window be defined.
1 3
To update an existing Workflow Configuration:

1. Drill down the tree branch on the left and choose the relevant Event class
2. Processing Organization (this could be ‘ALL’)
3. Product (this could be ‘ALL’)
4. Subtype (this could be ‘ALL’)
2
3
4
5. Once the table on the right brings up the Workflow, add/adjust by using the top portion of the
workflow
166
Notes:
6 7
6. Click ‘Save’
7. To delete, highlight the transition and click ‘Delete’
The ‘Duplicate’ button is also present in the Table View of Workflow.
Characteristics of Workflow
As explained earlier, the characteristics of a Workflow transition can be defined using either the
Workflow graph or the Workflow tabular window.
If you use the Workflow table, the characteristics of a transaction are visible as part of the main
window in the top portion of the right pane. If you use the Workflow Graph, the characteristics of a
transaction are configured using the Workflow action window. You can access the Workflow Action
window via several methods.
Main Entry > Configuration > Workflow > Workflow Graph
With icon activated from the top toolbar:

• By double clicking a status on the graph
167
Notes:
• By double clicking an existing action line
By right clicking an existing action line and choosing properties
With icon activated from the top toolbar:

• By linking one status to another with cursor
• By double clicking an existing status
Whichever way you decide to configure the details of a particular transaction (graph or table), the
characteristics which define the behavior of a transaction remain the same. These fields define how
the user or system will carry out an action in the Workflow step.
In the sections below, we will explain the different characteristics and their implications.
Different User: If checked, tells the system that user who promoted the object to its current
status (original status) has to be a different user than the user moving this
object to the next status by applying the current action. For example, when
activated, this could serve to forbid a user for ‘AUTHORIZING’ his/her own
trade amendments. This allows using the “four-eyes” principle.
Create Task: This checkbox allows users to define tasks that will not have Straight-
Through-Processing (STP). In other words, by checking this, users are
defining that the particular task is manual and will be performed through the
intervention of the responsible personnel.
Use STP: Alternatively, if a user requires transition to be automatically applied without
manual intervention. This applies the Straight-Through-Processing logic on a
task.
Use KickOff/Cut Off: Allows users to determine if a certain transition needs to be triggered at a
certain date and time and/or needs to be stopped at a certain date and time.
Priority: When there are several STP tasks from a given original status, setting a
priority number allows the user to define a priority for the order of execution
of STP tasks. By default it is set to 0 (highest priority).
168
Notes:
Log Completed: Indicates whether, when a particular Workflow step is completed by the
automated STP, the system will save a ‘COMPLETED’ task record to log this
step.
Preferred Action: If an originating status has many actions that can be applied to it and none of
the actions are STP (this is unlike the priority checkbox – view above – which
applies to STP actions), then the user can indicate which of those actions
take precedence. This only applies to trade Workflow.
We can see a preferred transition on the Trade Screen details Tab; the preferred action will
be the one to be displayed in the action combo box.
Update Only: In the event there is a transition where the original status and the resulting
status is the same, checking this box will insure that the system does not
create a new task but updates the existing task. For example, you have the
transitions NONE - NEW - PENDING (‘Create Task’ checked) and PENDING
- UPDATE - PENDING (‘Create Task’ and ‘Update Only’ checked). If you
apply
– VerifiedEventFilter - It theany
accepts UPDATE action,
trade (except the task
for trades created
in status on the
PRICING NEW action
or PENDING). Note will
that be
event
filters can be customized
updated, instead of a new task being created.
Generate Intermediary Event: In the event there are two consecutive STP transactions, when
checked, the system will generate an event for the intermediary STP
transition.
For example, for the message Workflow, you had these two STP transitions following one another:
PENDING > AUTHORIZE > VERIFIED and then VERIFIED > SEND > SENT
• If “Generate Intermediary Event” is not checked, a single message event will be generated for
“Message SENT” on the resulting status
• If “Generate Intermediary Event” is checked, two message events are generated: one for
“Message VERIFIED”, and one for “Message SENT”
This only applies to Trade Workflows and Message Workflows. For Transfer Workflows, you
can use the custom transfer rule "GenerateEvent."
Needs Manual Authorization: Check to indicate that the task requires manual authorization. If
checked, a transition will not be completed until the task created relating to
that transition has been accepted. This allows using the “four-eyes” principle.
169
Notes:
This only applies to the Trade Workflow and to non-STP tasks.
The bottom section of the Workflow transition configuration of the Workflow Action window (if using
the Workflow Graph) or the Workflow Configuration window (if using the Workflow config window)
allows a user to define conditions to Workflow actions.
Rules: The ellipses button will open the ‘Select Rules’ window from which users can
select the validation rules that have to be successful for a particular action/
step to be applied by the automatic STP Workflow. The transition will not be
completed unless the rules are satisfied. If the rules are not satisfied, an
exception will be raised in the task station.
Filter: Clicking on the ellipses button will open up the Static Data filter to allow you
to select a previously saved static data filter to be applied to the transaction.
Custom Rules Def: This button allows you to create custom Workflow rules, add conditions
and/or group Workflow rules.
Comment: This allows users to enter a free-form comment to describe the transition. It will be used
as a tooltip within the Task Station.
170
Notes:
171
Notes:
6.4 Focus on Some Configuration Concepts

To help users understand the way in which the activation of certain checkboxes determines the
behavior of the Workflow, this section will discuss in greater detail – giving examples - a few of the
functionalities listed above.
Task Creation
In the event that a particular action (step) is not required to be automated but a user intervention is
preferred, when setting up the transaction, users need to check the ‘Create Task’ checkbox. For an
action to be applied manually, it is mandatory to create a task.
This way, once the task reaches the stage where it is no longer performed through STP (Calypso
creates a task when the object reaches the resulting status), it will stop – and a task will be created in
the Task Station to allow a user to transact the action manually.
Let’s assume you have a trade input and the trade, having been saved by the Front Office, requires
the trading assistant/Middle Office to review details with the executing party or brokers/counterparties.
The trading assistant/Middle Office user will confirm details such as trade Counterparty name,
amount, direction, broker name, fee amount, etc., before acknowledging the trade and pushing it
down the lifecycle to the Back Office by applying a specific action.
Thereafter, if there are no more tasks to be performed on the trade, the Back Office can take the trade
and begin to work on the various Back Office components once the trade reaches VERIFIED status OR
status XYZ (dependent on configuration).
Of course, once the Back Office has the trade, there could be amendments that need to be done on
the trade, but we will cover that will be covered in the Four-Eyes section of the module.
Remembering that a task is created when the object reaches the resulting status. To accommodate
for this (the business practice in the example above of the Front Office saving trades and ta/middle
office confirming), the following trade lifecycle transition has been put in place:
172
Notes:
In the following modules, we will progress through the above workflow giving you examples along the
way.
Taking the below workflow transitions into account, let us review what occurs when:
• “Create Task” is checked on the transition
PRICING > PENDING_ORDER > CONFIRM_ORDER
Original Status Action Resulting Status Task Users/Executors
NONE NEW PRICING Trader
PRICING PENDING_ORDER CONFIRM_ORDER Yes System
CONFIRM_ORDER MO_AMEND PENDING ta/middle office
PENDING AUTHORIZE VERIFIED Yes System
The system will ensure that when the trade reaches the CONFIRM_ORDER status, a user can
manually apply the MO_AMEND action.
For this manual transaction example, we will assume the user applying the action (MO_AMEND) is
the trading assistant/Middle Office user. When the trade reaches CONFIRM_ORDER (resulting
status), the system creates a task.
Below is a trade where a trade (Equity) has been input and the trade has stopped at
CONFIRM_ORDER.
The trading assistant/Middle Office user now has to apply the action MO_AMEND on the transition
CONFIRM_ORDER > MO_AMEND > PENDING. This can be done manually.
173
Notes:
• When ‘Create Task’ is checked on the transition
PENDING > AUTHORIZE > VERIFIED
Original Status Action Resulting Status Task Users/Executors
NONE NEW PRICING Yes Trader
PRICING PENDING_ORDER CONFIRM_ORDER Yes System
PENDING AUTHORIZE VERIFIED Yes System
The system will ensure that when the trade reaches the VERIFIED status, a task is created on the
following transition after VERIFIED (and if circumstances require a user to), can manually apply
whatever the following action is.
Task and STP

In the first manual transaction ‘Check Task’ example above, we reviewed when the trade reached
CONFIRM_ORDER (resulting status), the system would create a task for the ta/Middle Office user to
apply the action MO_AMEND.
Original Status Action Resulting Status Task STP Users/Executors
NEW PRICING Trader

NONE
CONFIRM_ORDE
PENDING_ORDER R Yes Yes System
PRICING
MO_AMEND PENDING ta/middle office
CONFIRM_ORDER
AUTHORIZE VERIFIED Yes Yes System
PENDING
The resulting status ‘PENDING’ (after the ta/Middle Office has completed their task) happens to be an
originating transaction, which has an STP action (step) AUTHORIZE.
In the table above, this STP transition has been flagged where the ‘Users/Executors’ has been stated
to be ‘System.’ This means that the system will automatically try to ‘authorize’ the trade when it
reaches the PENDING status.
As a result, once the ta/Middle Office user has applied the manual action MO_AMEND, the trade will
actually move through CONFIRM_ORDER > MO_AMEND (manual intervention) > PENDING >
AUTHORIZE (system automated) > VERIFIED. This is because Calypso Workflow functionality works
in conjunction with manual tasks and STP transitions.
174
Notes:
Should the manual intervention fail (i.e., when the ta/Middle Office applies the MO_AMEND action the
task cannot move), even though the transaction does not have ‘create task’ Calypso would create an
‘Exception’.
• Had “Create Task” been checked on the transition
CONFIRM_ORDER > MO_AMEND > PENDING
PRICING PENDING_ORDER CONFIRM_ORDER Yes Yes System
CONFIRM_ORDER MO_AMEND PENDING Yes ta/middle office
PENDING AUTHORIZE VERIFIED Yes Yes System
When the ta/Middle Office applies the action MO_AMEND, the STP transition would still execute and
the trade would be in ‘VERIFIED’ status.
In this case, Calypso would create a task on the PENDING status, but as the STP executed with no
issue, the task will appear as COMPLETED (i.e., nothing for a user to do). Our next module will
highlight where the task will appear as ‘COMPLETED.’
General Rule of thumb for Create Task and STP:

A task is created when the object reaches the resulting status. If you have an STP (Straight-Through-
Processing) transition which is followed by a manual transition:
PRICING > PENDING_ORDER > CONFIRM_ORDER (STP)

CONFIRM_ORDER > MO_AMEND > PENDING (MANUAL)
You will need to check ‘Create Task’ on the STP transition so that when the object reaches the final
STP status, a task will appear for the appropriate user to process. If you have STP unchecked on a
transaction to apply the action of the transition manually:
CONFIRM_ORDER > MO_AMEND > PENDING (Create Task unchecked and Not STP)
175
Notes:
The preceding transition should have “Create Task” checked.

Pricing > PENDING_ORDER > CONFIRM_ORDER (Create Task checked)
This way a task will appear for user to process for the current transition. Unless two consecutive
transitions are STP, when “Use STP” is checked:
Pricing > PENDING_ORDER > CONFIRM_ORDER (STP Checked)
AND:
PENDING > AUTHORIZE > VERIFIED (STP Checked)
The “Create Task” box should also be checked. Once the object reaches its resulting status, the
system will be allowed to carry out any further required processing on the object.
Rule Creation
In general, an automatic transition (STP transition) should be associated with a rule, so it is only
applied if the rule is satisfied. Rules refer to validation criteria. They determine whether the action
(step) will be applied by the automatic STP Workflow.
We will review below the two different ways in which Calypso allows users to define rules.
Calypso Out-of-the-Box Rules

Calypso offers a wide range of out-of-the-Box Trade/Message & Transfer Workflow Rules.
In order to configure a rule for a particular Workflow step, you will need to open the ellipses button
next to the Rules field. This will open the ‘Select Rules’ window, from which users will be able to
search for their desired rule by using the search field (circled below) and moving the rule type from
the left section of the selection window to the right.
On Workflow transition:
Let us add the Workflow rule ‘CheckLegalAgreement.’ This rule returns false if the system does not
find a legal agreement signed with the counterparty. If there is not a legitimate Legal Agreement found
176
Notes:
between the Processing Organization and the Counterparty, then STP would be stopped and the
trade will remain in PRICING status.
Should however the rule return true (as per below screenshot), meaning the system does find a
corresponding Legal Agreement, then the trade will be moved on to CONFIRM_ORDER, giving the
ta/Middle Office the ability to confirm details with the execution agents and manually push the trade
through by applying the MO_AMEND action.
• The system has found a corresponding Legal Agreement between our Processing Organization
CUB and ‘Chase NY’
• When there is not a valid Legal Agreement for the Processing Organization and Counterparty and
the trade is saved, here is the trade, stuck in PRICING status
177
Notes:
• The system has not found a corresponding Legal Agreement between our Processing
Organization CUB and ‘BK XYZ’
The available Workflow rules per PSEvent are available in the Calypso Documentation and can also
be viewed via:
Main Entry > Configuration > System > Domain Values
§ WorkflowRuleTrade
§ WorkflowRuleTransfer
§ WorkflowRuleMessage
Custom Rules
Should the Calypso out-of-the box Workflow rules not match your desired needs, Calypso also
provides a possibility to create custom rules.
Users can define their own custom rules by clicking on the ‘Custom Rules Definition’ button. Via this
window, users can create custom rules from scratch, or create custom rules using existing out-of-the-
box or already customized rules. The later would be a form of extending rules into other rules.
In this example, let us assume that a particular Counterparty’s credit rating has severely dropped and
you would like to create a rule which blocks trades with that particular Counterparty and not other
counterparties. For this scenario, we would open the ‘Custom Rules Definition’ window and define our
custom rule specifying that a transition will be applied on all other trades that have a different
counterparty than Chase.
178
Notes:
The name of the

Counterparty is its
short code, and
this is a case-
sensitive string
• Types: Determine the relevant PSEvent which you will require your rule for. We have defined
PSEventTrade
• Other Rules: Shows you all the existing validation rules for the relevant PSEvent ‘Chosen.’ The
list includes both Calypso out-of-the-box rules and your previously configured custom rules
• Available Fields: These are predefined set of attributes which are also in respect to the relevant
PSEvent chosen
For information on implementing custom rules that cannot be handled by the predefined
set of attributes, refer to the Calypso Developer’s Guide.
• Rule expression: This field maintains your custom rule ‘argument’. You can create your new rule
by:
Combining existing validation rules with your own rules
Combining existing validation rules with available Fields
In our example, we have defined Trade.Counterparty = ‘’CHASE NY’’ For the full list of arguments you
can use in your custom rule, please refer to the screenshot below titled ‘Custom Workflow Rule
Arguments.’
In this argument, ‘Trade’ represents the PSEvent, ‘Counterparty’ a trade attribute within the Available
Fields list, ‘!’ representing false, ‘=’ representing equals and ‘’CHASE NY’’ representing the
counterparty short name. The rule basically states that the trade counterparty should not be CHASE
NY.
• Apply the ‘Save As’ button and name rule as Cpty NOT Chase
179
Notes:
• The name will show up in the Name Field
Custom Workflow Rule Arguments

You can use the below values in any way to create customized rules,
provided that the final result is a boolean indicating whether the Workflow
will allow to proceed to the next step or not.
--- Basic Values ---

+ numbers and basic arithmetic operators (+, -, *, /)
+ boolean constants "true" and "false"
+ boolean operators "!" (not), "||" (or) and "&&" (and)
+ comparison operators ==, !=, <, <=, >, >=
+ Character strings, enclosed by double quotes '"', like
"This is a String"
+ Dates, written using this format: mm/dd/yyyy
ie: 12/25/2001 is a valid date
+ Time of day, using this format: hh:mm with an optional (am or pm)
ie: 11:38am, 5:02pm, 22:00, 4:05 are all valid times
Going back to reviewing Workflow (in the same fashion as the earlier example when we added the
Calypso out-of-the-box rule CheckLegalAgreement), on the second STP transition if we were to use
our custom rule, we would be able to see how this new rule affects one of our STP transactions.
Original Resulting
Action Task STP Rules Users/Executors
Status Status
CheckLegalA
PRICING PENDING_O CONFIRM_OR greem
RDER DER Yes Yes ent System
CONFIRM_OR
DER
Cpty NOT
PENDING
AUTHORIZE VERIFIED Yes Yes Chase System
180
Notes:
With the above configuration in place, what we expect is:

• Original trade input between PO and Chase NY will have passed the first STP transition rule
‘CheckLegalAgreement’ and would now stop at CONFIRM_ORDER
• At CONFIRM_ORDER, the trading assistant/Middle office (after confirming details) of the trade
will transact the manual action MO_AMEND
• Once the MO_AMEND task has been conducted by the ta/Middle Office user, the trade would stop
at PENDING status. The ‘Cpty NOT Chase’ rule on the proceeding STP transaction would have
returned true because the custom trade rule indicates that transactions with any Cpty BUT Chase
can pass
181
Notes:
• Calypso would create a task for this break
Assuming a LegalAgreement existed between Processing Organization and BK XYZ,

when a trade was transacted between PO and BK XYZ the initial STP rule would not have broken
neither the second.
Defining a Conditional Custom Rule

Should users want to create a custom rule where conditions are added as part of the rule, then the
‘if/then/else’ scenario can be used.
Below is an example:
182
Notes:
The parser
2
is case-
insensitive
1. Types: As above, determine the relevant PSEvent which you require your rule for. We have
defined PSEventTrade
2. If/then/else: This section can be used to define (insert) arguments. Which means in the ‘If’
section, you would need to specify your rule using a combination of Other Rules, Available
Fields and your condition
The logic which is applied is X ? Y: Z which implies, if (X), then do Y. Otherwise do Z.
3. Insert Test: When you apply the ‘Insert Test’ button the system will apply your rule
(configured in the if/then/else fields) using the formula required into the Rule Expression
section
4. Rule Expression: The arguments you have defined using the if/then/else logic will be added
into this section when you apply the ‘Insert Test’ button. They will be filled in this field
automatically. The argument specified here is the argument for your custom rule
Taking the X ? Y: Z logic, in our case we have told the rule ‘if’’ Trade Counterparty is
Chase, ‘then’ apply the CheckCutOff rule. Otherwise’ (for all other Counterparties) do
not apply.
5. Select the ‘Save As’ button and name rule as On Chase Apply Cut Off
6. The name will show up in the Name Field
183
Notes:
Defining Grouping Using Custom rules.

Users can setup Custom rules to group multiple Workflow rules for a given transition and enforce their
order of execution. An example could be if you want to write a rule that checks the SDI and if the
trade is mature. In order to know what steps to conduct to save the rule, review either custom rule
example number 1 or 2 above. This is done by just writing the name of the rule followed by 2
parentheses.
Like this: CheckSDI() && CheckMature()
When ordering rules, the system will first check that all the rules are satisfied, and then perform any
processing specified in the rules.
You can also use Static Data Filters as part of your Custom Rule. You would need to write it as:
Filter.NameOfTheFilter and this will return a boolean value indicating whether the trade, message or
transfer has passed through the filter successfully.
Kick Off/Cut Off

The Kick Off/Cut Off functionality allows users to set a kick-off timer (which allows triggering the
transition at a certain date and time) and/or a cut-off alert (which allows sending an alert if the
transition has not been completed by a certain date and time). This could become useful for example
in the event that between certain specific hours of the day, Back Office users need to send or
generate messages/payments, etc.
184
Notes:
For example, let us say that in a certain market, confirmation messages need to be sent to agents
between specific hours. If a certain Back office user was responsible for sending these messages
between the set times and he/she had many messages to take care of, then automating the
messages to be sent would be helpful.

Automatic
Settlement of
Messages in
VERIFIED Status
(checks 15 sec

intervals)

Messages in

VERIFIED Automation stops

SOD
EOD

Start Kick O ff Off
Cut

Below we will go through a few details that would help achieve this. In order to use the Kick Off/Cut
Off functionality, a few items need to be in place.
Remember at the beginning of ‘Workflow’ we had mentioned that there was no need for an Engine.
There is in fact an exception to the rule for this instance. For the Kick Off/Cut Off functionality, the
Task Engine must be running. This Engine is in charge of attempting the transitions with a timer.
Assuming the Message Workflow transition exists between VERIFIED > SEND > SENT, you would
configure a Kick Off / Cut Off to apply on this Workflow transition by adding the Workflow rules
CheckKickOff or CheckCutOff, depending on the timers required. In our example we are assuming
Messages need to be sent between certain hours, we are going to need both rules. We will review
configuration details below.
185
Notes:
Kick Off / Cut Off

logic ONLY applies
to STP transitions.
To access Kick Off/ Cut Off details, navigate to:
. Main Entry > Configuration > Workflow > Kick Off/Cut Off
3
4
186
Notes:
1. When the window opens, the Browser panel is selected by default

To search for existing KickOff/ CutOff configurations, use the search criteria as
applicable.
2. To search for existing KickOff/ CutOff configurations, use the search criteria as applicable
When the Workflow Selector window opens, you will need to select the relevant
PO/PSEvent/Product and possibly the subtype. The system will only load the Workflow
transitions that have the Kick Off/Cut Off checkbox checked in the Workflow configuration.
Select the Workflow transition that corresponds to what you are looking for, and ‘Apply.’
The definitions of the search criteria are available are described in the table below.
Fields Description
Receiver
Click on to select a Legal Entity from the Legal entity Chooser.
For Trade and Transfer Kick Off/ Cut Off, the receiver is the Counterparty. For
Message Kick Off/Cut Off, the receiver depends on the type of message (thus
subtype) and who the message receiver is.
Method Select method from dropdown menu: All, Email, Fax, Mail, Swift, Telex
For Trade and Transfer Kick Off/ Cut Off, the Method is the SDI method used,
for Message Kick Off/Cut Off, the Method depends on the Method the message
setup is using to send the particular message type.
Currency Select Currency from dropdown menu.
Date Calculator Select data calculator from drop down menu.

By default, the task execution / alert is triggered based on the task date time.
However, this can be overridden by implementing the date calculator that of your
choice.
187
Notes:
Fields Description
SD Filter
Click on to select an existing static data filter from the selector for restricting
the application of the timer/alert
Date Roll Choose a date roll convention from the dropdown menu. For details on date roll
conventions, please refer to Calypso Documentation
Holidays
Click on to open a Selector window from which you can select the holiday
calendars for calculating business days.
Time Zone Select time zone from dropdown
3. Once you have defined your criteria, click ‘Load’

4. If there are existing configurations, they will appear in the bottom section of the window. You
will need to select a row and double click and the system will direct you to the Edit panel (shown
below)
If there is no any Kick Off / Cut Off specification for the timer and/or alert, to define Kick Off/Cut Off
specifications, you will need to use the Edit menu to input the desired characteristics according to
your Kick Off/Cut Off needs.
Some of the fields in this panel and their description have already been covered when discussing the
search criteria details (review point 2 above). For this next section, we will now focus on the remaining
definition fields available that will allow users to determine the precisions of their Kick Off/Cut off
configuration.
3
4
1 5
6 7
8
2
9
188
Notes:
Fields Description
1. Check Holiday If this flag is checked (true), it will incorporate the selected Holidays
Checkbox into the calculation of the Kickoff/Cutoff times.
When not checked, the holidays selected in the Holidays field will not
be applied.
2. Absolute Time Check the “Absolute Time” checkbox to set the timer/alert at a fixed
time or on task creation time. Explained in detail later.
3. KickOff days lag Enter number of lag days to start the task according to today.
4. Kickoff Time Enter Kick Off time. It is absolute or relative based on the “Absolute
Time” checkbox.
5. No Cutoff Select this if you do not want to specify a cut off time/date.
6. CutOff days lag In the event that “No CutOff” is unchecked. Then you need to
determine the number of lag days to send an alert if the task is not
completed.
7. CutOff Time Enter Cut Off time. It is absolute or relative based on the “Absolute
Time” checkbox.
8. Scan Frequency Determine the frequency at which the Task Engine should try the
Workflow task.
9. New/Delete/Save & These buttons allow you to add a new configuration, delete an
Save As New existing one (you would need to do this once having pulled up the
relevant one in the top section, The existing one would show in the
table below), loading and modifying an existing one and ‘Saving as
New.’
For example, the absolute time allows users to define the Kick Off and Cut Off times relative to the
time the task is created.
So, in our example, when the Message is in VERIFIED status if the absolute time is set to true, then
the Kick Off/Cut Off will apply on the task at the exact time defined in the ‘’hh’’ and ‘’mm’’ boxes of the
Kick Off/Cut Off time boxes. If the Message was in VERIFIED status, you would set up a start and
end time for the system to try the task and send it to the next Status. Between the Kick Off time and
Cut Off time, all the VERIFIED Messages would have been sent out within the time period that
agents/exchanges usually receive them.
Let’s say (as shown in our screenshot below) you have Kick Off HH set as 17:30 and MM=30. Your
Cut Off HH is set at 19 and MM 30. Assuming that Lag is 0, the Kick Off will apply at 17:30 am and
the Cut Off will apply at 19:30 for the date the message should be sent. As currencies can be
specified, this could be useful in the event that different Kick Off/Cut Off’s apply for different
currencies/exchanges, etc.
189
Notes:
If the absolute time is turned off, then the system reads the HH and MM as hours and minutes relative
to the task creation time. So, if HH=17 and MM=30 (and lag=0) then the Kick Off will be 17 hours and
30 minutes after the VERIFIED message is created and the Cut Off will be applied 19 hours and 30
minutes after the VERIFIED message is created.
The below example is a set up for how often the Task Engine should move the messages in
VERIFIED status to SENT on the STP transition that has the Kick Off attached to it.
Continuing on with our example, we have a Kick Off attached to a Message transition VERIFIED >
SEND > SENT. Now if we add a scan frequency of 15 seconds, this means that if there are any
VERIFIED messages, the system will apply the Kick Off to these messages (taking into consideration
the absolute time) moving them to the transition VERIFIED > SEND > SENT every 15 seconds.
For the Kick Off/Cut Off to work, the Task Engine needs to be running and subscribing to
PSEventTask.
190
Notes:
6.5 Workflow and 4-Eyes Principle

In this section, we will be covering the principles of Workflow and authorization, otherwise known as
the ‘4-eyes’ principle.
The idea behind this principle is to put checks and controls on approval processes in areas where
business decisions and transactions could have an undesired effect. It is known as the ‘4-eye’
principle because at a minimum there is the initial ‘‘executer’ (2 eyes) and his ‘approver’ (2 eyes).
This forms a reporting/approval process that can protect an organization from incorrect workflow.
Building on the Workflow setup we have already gone through, we will cover the various different
ways Calypso supports the 4-eye principle.
Original Workflow
Original Status Action Resulting Status Task STP Rules Users/Executors

PENDING_
PRICING ORDE CheckLegalAgr
R CONFIRM_ORDER Yes Yes eement System
CONFIRM_OR
DER
Cpty NOT
PENDING
The workflow discussed during the Task and STP scenario has shown us a couple of trades where
the below has occurred:
• Trade done with Chase NY has passed first STP and moved to CONFIRM_ORDER (before
breaking on second STP)
• Trade done with BK XYZ has stopped at PRICING (due to lack of Legal Agreement)
Different User
To show how ‘Different User’ could be used, let’s go through a scenario where one of the trades has
passed the STP checks.
1. Initial trade is saved by the front office
2. The trading assistant/middle office reviews/confirms details with the relevant executing parties
3. The trading assistant/middle office user saves the trade and the trade arrives at VERIFIED status
4. Back office now has the trade and the trade’s back office components have been generated
The change could be instigated by a number of events or a number of sources, but for this case, let
us assume the Back Office user makes the amendments/updates to the trade. It can be something
191
Notes:
like a change of trader name/broker name, etc. The back office user, if he/she has rights to make
amendments (this is dependent on access permission rights) thus will make that change. To apply the
‘four-eye’ principle, his/her change will need to be approved by someone.
In the event that the approver is someone within the same department, this kind of scenario could be
addressed by the use of the field ‘Different User.’ This approval process is between users within the
same group. Correct Workflow setup needs to be in place to handle this four-eye process.
The setup could be something like:
Diff
Resulting Users/Exe
Original Status Action Task STP Use Rules
Status cutors
r
CONFIRM_ checkLegalAgree
PRICING PENDING_OR ORDE ment/
DER R Yes Yes CheckSDI System
ta/middle
CONFIRM_ORDE
offic
R
MO_AMEND PENDING e
PENDING AUTHORIZE VERIFIED Yes Yes Cpty NOT Chase System

Assuming BO User 1 needs to make changes/updates on trade. Here BO User 1 applies
BO_AMEND action.
PENDING_F
VERIFIED O_AM
BO_AMEND END Yes bo (user 1)
PENDING_FO_AM
BO_AMEND VERIFIED Yes CheckNoChange bo (user 2)
END
PENDING_FO_AM
REJECT VERIFIED reject bo (user 2)
END
You will notice that we have added an additional Rule (CheckSDI). This is to insure that the system
finds the correct SDI’s to apply to transfers before generating them. Apart from that, the top part of the
Workflow is what we were working on earlier. What has now changed on this Workflow is the bottom
portion of the table. This is to accommodate changes being done (after the trade has been verified)
and to support the 4-eye principle.
To support intergroup modifications, we have added:
VERIFIED > BO_AMEND > PENDING_FO_AMEND
The transition to be applied by the Back Office user who will make the amendment:
PENDING _FO_AMEND > BO_AMEND > VERIFIED
PENDING _FO_AMEND > REJECT > VERIFIED
In the Workflow transactions shown above, we are assuming that once the trade reaches the status
‘VERIFIED,’ the Back Office user is working on the components (managing its transfers/messages,
etc).
192
Notes:
Once an amendment/change has been deemed necessary on the trade and a Back Office user
decides to amend something, they will make the change by applying the action BO_AMEND action.
On this transition, we have ‘Create task’ set as we require the approving user to be notified of change
and to be able to either accept or reject.
When the trade is in VERIFIED status, BO ops (back office operations) user 1 will make the
amendment and save (applying the manual action BO_AMEND). The trade will arrive at
PENDING_FO_AMEND status.
The ‘Different User’ checkbox being checked at:
PENDING_FO_AMEND > BO_AMEND > VERIFIED
This ensures that the user applying this action is not the same person, thus adhering to the 4-eye
principle. For the ‘Different User’ scenario, two transitions are necessary for the approval/rejection
process.
Note that these two users are in the same group. In order to make sure that the 4-eye principle is
logical, we have implemented the rule ‘CheckNoChange.’ This rule checks that the approver is
approving the process without modifying the trade.
Manual Authorization
Using Manual Authorization within the Workflow is similar to using the ‘Different User’ logic, in that this
approval process is between different users within the same department (access group). The
difference being the ‘Different User’ functionality does it in one step.
To show this functionality, as in the case of the ‘Different User’ scenario where one of the trades has
passed the STP checks, we will assume:
2. The trading assistant/middle office reviews/confirms details with the relevant executing
parties, etc.
3. The trading assistant/middle office user saves the trade and the trade arrives at VERIFIED
status
4. Back office now has the trade and its back office components have been generated
In the same format as the ‘Different User’, let’s say once the trade moves to the Back Office, some
detail needs to be changed.
The one difference between ‘Different User’ and ‘Manual Authorization’ is that instead of the changes
being made and the Calypso Workflow transaction having to have two other Workflow transaction
setups for the approver to accept/reject change, the ‘Manual Authorization’ functionality allows this
process to occur in one transaction and in addition, allows the process (change, approval/rejection) to
be conducted using the Task Station
An example of the setup we could apply is below:
Original Resulting Ta Man Users/Exec Access

Action STP Rule
Status Status sk Auth utors Perm
NONE NEW PRICING Yes Trader trader
193
Notes:
Original Resulting Ta Man Users/Exec Access

Action STP Rule
Status Status sk Auth utors Perm
checkLegalA
PRICING CONFIRM_ greeme
PENDING_OR ORD nt/Che
DER ER Yes Yes ckSDI System
CONFIRM ta/middle
_ORDER MO_AMEND PENDING office ta/middle
Cpty NOT
PENDING
Assume the front office or ta informed BO 1 User 1 to make change/updates on trade.
Here BO User 1 applies FO_AMEND action
This particular Workflow transaction accommodates the 4-eyes principle and shows how manual
authorization logic works.
In the Workflow transactions shown above, we are assuming that once the trade reaches the resulting
Status ‘VERIFIED,’ the Back Office user is working on components (managing transfers and
messages). At the point where the Back Office user is required to make the amendments, Bo ops
user 1 will make the change and apply the manual action FO_AMEND. Where in the earlier section
(Different User) we had two transactions with rules setup up for the approver:
PENDING_FO_AMEND > REJECT > VERIFIED
The logic here is when the first BO ops user makes the change and applies FO_AMEND, the system
generates an exception for the approver. This exception is EX_TRADE_AUTH. The change made by
the Bo ops user 1 stays in a static status without being applied (remains in its initial VERIFIED status),
until the approver Bo ops User 2 accepts or rejects.
If the approver accepts, then the changes on the trade are approved. The changes made by the Bo
ops user 1 become effective. The resulting status, once approved, will be VERIFIED with the
amendments in place. If the approver rejects the task, the trade will remain in is original status
VERIFIED without any changes being applied.
For this process to work smoothly, in addition to the Workflow transaction, there is an additional setup
that needs to be in place.
• The manual actions to be authorized in the Workflow transition must have the checkbox “Needs
manual Authorization” checked
194
Notes:
Setting up the trade Workflow rule CheckPendingModifications as part of your manual

authorization transition will work in collaboration with the mandatoryTradeRule domain value (covered
in point ‘c’ below) to insure that no other user can make an update to the trade until the original
change has been approved or rejected.
Main Entry > Configuration > User Access Control > Access Permission
The access
permission
needs to
remain on the
left of the
window.
Workflow and Access Permissions

Another way to apply the 4-eyes principle is by combining Workflow actions with Access Permission
rights.
In the above two examples (Different User and Manual Authorization), the 4-eyes principle was
applied for users within the same group. The Calypso Workflow access permission functionality
allows users to apply the 4-eye principle across groups.
2. The Middle Office reviews/confirms details with the relevant executing parties
3. The Middle Office user saves the trade and the trade arrives at VERIFIED status
4. The Back Office now has the trade and the Back Office components have been generated
Now, instead of the Back Office making the modification (as in the previous two cases), we will
assume once the trade is in VERIFIED status and the Back Office personnel are working on it, and
modification needs to be done by the Middle Office. These users are in a different department
(Access Group) than the Back Office operations users.
195
Notes:
To allow for this, we have put the below Workflow transition in place:
Original Resulting Tas Users / Access

Action STP Rule
Status Status k Executors Perm
NONE NEW PRICING Yes Trader trader
CheckLegalAgree
PRICING PENDING_OR CONFIRM_O ment/Check
DER RDER Yes Yes SDI System
CONFIRM_ ta/middle
ORDER MO_AMEND PENDING office middle
PENDING AUTHORIZE VERIFIED Yes Yes Cpty NOT Chase System
Assuming Front office/Trading Assistant needs to change details of trade (example

quantity/direction, etc) after it is VERIFIED
PENDING_FO
VERIFIED _AMEN ta/middle
BO_AMEND D Yes office middle
bo ops User
PENDING_F
1 or
O_AMEND
BO_AMEND VERIFIED CheckNoChange 2 bo/ops
bo ops User
PENDING_F
1 or
O_AMEND
REJECT VERIFIED reject 2 bo/ops
In this example, we are assuming that the Middle Office personnel will make the amendments to the
trade once it has reached VERIFIED and Back Office users are working on the components. The
Middle Office user will apply the BO_AMEND action.
You can see from the table above that for this scenario, much like the ‘Different User’ scenario, it is
necessary that there are two transactions for the approval/rejection processor:
PENDING_FO_AMEND > BO_AMEND > VERIFIED or PENDING_FO_AMEND > REJECT >
VERIFIED
Rules have also been put in place on each transaction to either check that the approver is not
modifying more than the initial change or that in the case of REJECT, and the trade goes back to its
original transaction before the change. The Middle Office is able to make this amendment because
they have been given access rights to conduct this step.
This means that the Middle Office user needs to have workflow access rights for status VERIFIED
and action BO_AMEND and the BO user needs to have access rights for both:
and
PENDING_FO_AMEND > REJECT > VERIFIED
The screenshot below shows the setup:
196
Notes:
Once the Middle Office user has made changes, someone in a different group can accept or reject the
changes.
197
Notes:
6.6 Transfer and Message Workflow

Although we have focused on Trade workflow above, all other workflow details explained above apply
to both Transfers and Message Workflows, meaning, in the same way as trades move down the
lifecycle conveyer belt, so do transfers and messages.
Transfer Workflow
The following screenshot shows the transfer workflow. Transfer actions and the corresponding status
codes are also described in the table below.
198
Notes:
Transfer Actions and Status Codes
NEW New transfer is PENDING

created.
AMEND User edits the transfer Usually no change in

(payments), or user objects status i.e.,
edits the trade, remains in PENDING.
resulting in an edit to
the transfer.
AUTHORIZE User marks payment VERIFIED When a transfer is

as ‘checked and ready VERIFIED, the
to be sent’ Inventory Engine
processes it.
FAIL User specifies that the FAILED

transfer has not been
executed.
SETTLE The transfer is settled. SETTLED When a transfer is

This Action is available SETTLED, the
from the Task Station. Inventory Engine
The user can specify updates related
the actual settlement inventory positions.
date and actual Once a transfer is
settlement amount. SETTLED, the Transfer
These are stored along Engine can no longer
with the original modify it.
scheduled date and
amount.
CANCEL User cancels the CANCELED IF a payment is

transfer. CANCELED, the
following Engines will
handle the necessary
recalculations and
actions:
Accounting Engine *
Inventory Engine
Liquidation Engine
Message Engine
Transfer Engine
ASSIGN User assigns Usually no change The current transfer is

settlement Instructions canceled and replaced
to one transfer, by a new one.
individually (SDI status
code ‘Xfer Assigned’).
This Action is available
from the Task Station.
199
Notes:
Message Workflow
The following screenshot shows the Message workflow. Message actions and the corresponding
status codes are described in the table below.
200
Notes:
Message Actions and Status Codes
Action Description Typical Result Status
NEW User creates a new message. PENDING
AMEND User edits the message, or the Usually no change in object’s status
trade, resulting in an edit to the
message.
AUTHORIZE User marks the message as OK VERIFIED

and ready to send.
HOLD User places a hold on the HELD

message. It cannot be sent until
the HOLD is released.
SEND User sends message to the SENT

recipient
NACK Receiver sends a ‘nack’ message NACKED

indicating that the receiver DID
NOT get message correctly.
FIX User corrects a NACKED PENDING

message. This moves it to
PENDING and results in
revalidating the Message (to be
implemented).
ACK Receiver sends an ‘ack’ message ACKED

indicating that it was received
without any errors.
UNMATCH The system uses this action when UNMATCHED

the receiver of a message fails to
reply to the sent message.
MATCH Receiver sends a ‘match’ MATCHED

message, indicating that they
agree with the messages
contents.
MISMATCHED Receiver sends ‘mismatched’ MISMATCHED

message, indicating that they DO
NOT agree with the message’s
contents.
CANCEL User cancels the message. CANCELED
201
Notes:
Summary
Workflow is the combination of Engines, Events, and Access Permissions that move trades to a
verified status and ensure that Back Office components are generated. It is important to know that in
Calypso, all actions within the workflow logic can be configured, modified and locked per user, per
use case. Business need often dictates what an entity does with its workflow.
202
Notes:
Module 7: Monitoring and
Managing

• Set up users in the system
• Define Group Access Rights
• Define out-of-the-box or customized Task Station user

preferences
• Customize and set priority levels on tasks
• Explain how to disperse and manage different priorities of tasks

amongst users
• Define the drill down capabilities to related trades, transfers and

payments
• Add comments to underlying objects and tasks
• Configure the tracking capabilities of Task Station

MODULE 7 Monitoring and Managing
Introduction
In this module, we will discuss the Calypso Task Station.
The Task Station is used to display tasks, as defined in the various (Trade/Transfer/Message)
Workflows. It is the user interface to view and act on the tasks (manually) generated by users or the
system (exceptions). It is the main Back Office monitoring tool.
Back Office users in organizations rely on the speedy processing of trades in order to keep cash and
securities moving. The Task Station also gives a peek into the tasks themselves through reports that
can be run to show components contained within.
This module will conclude with multiple scenarios and examples of how users interact with the Task
Station, performing actions on trades and interacting with other users.
A Brief Review of Workflow Concepts

Calypso uses the Workflow system to monitor and manage the lifecycle of trades, transfers,
messages and other system-generated events.
Calypso Concepts to remember for this module:
The Workflow system creates tasks immediately in response to saved trades, edited data, errors, and
other activity as specified in the Workflow.
The Workflow system moves objects (tasks) from one status to another by applying Actions.
Status is linked to Actions and can be user configurable.
By defining actions as manual or STP, the Workflow system provides business organizations with the
ability to manage operational processes in an efficient manner.
A task is any step in the processing of a trade, a transfer of cash or securities, or a message such as
a trade confirmation/payment message.
The types of tasks we discussed included both manual tasks and STP tasks:
• Verification (for example: inputting of trades verifying that they moved to VERIFIED)
• Authorization (for example, the Manual Authorization scenario we discussed)
• Enrichment (for example, an amendment to a trade/transfer amount, reset addition,

message regeneration, etc.)
204
Notes:
7.1 Task Station Overview

The Task Station is used to display tasks, as defined in the various (Trade/Transfer/Message)
Workflows. It is the user interface to view and act on the tasks (manually) generated by users or the
system (exceptions). It is the main Back Office monitoring tool.
Users can carry out the lifecycle processing of Workflows, using the Task Station as a form of a
notification tool where they are alerted of all errors that occur in processing these tasks, with the
intention of allowing users to resolve these errors directly from the Task Station.
Depending on where the trade, transfer or message object is in the lifecycle, a task can be created
and will have a status based on its level of completion. This information is displayed in the Task
Station.
Using the Task Station, Back Office staff can do the following:
• Complete tasks by carrying out actions on them. The list of available actions for a task depends
on the user’s Workflow Access defined in the Access Permissions Window
• Claim ownership of a task. Owning a task means that no other user can perform an action on that
task
• Configure the Task Station Window to show only the types of activities for which the user is
responsible
• View all of the changes made during the life of a task’s related trade using Calypso’s auditing
scheme
The Task Station can be configured to the specific needs of particular work groups. For example, a
Processing Organization is typically structured into teams with each team having a defined set of
responsibilities.
There might be one team responsible for verifying trades, another for verifying settlements, another
for advices and yet another for EOD valuation or report processing. The Task Station of the different
team members can all be configured so that they show only the tasks for their respective teams. The
Task Stations of users can be further configured to show the tasks that the system is processing
automatically or only those that require manual intervention.
When someone begins working on a task, the team’s Task Stations are all immediately updated and
the task is locked so that nobody else can work on it at the same time. This avoids confusion about
responsibilities and eliminates duplication of effort. If you cannot resolve a problem or do not have the
time to investigate it, the task can be forwarded to another person with permissions to view the task,
say a supervisor. A message can be attached to the task explaining why it is being forwarded.
Since the Task Station is integrated with other Calypso applications, users do not have to go into
multiple places to track down information. From the window that shows the task, users can quickly
navigate to the trade that created the task, the related tasks that have already been executed, or any
other pertinent information. When the scheduled date for an activity approaches, an entry for the
appropriate person appears in the Task Station to ensure that the task is performed.
205
Notes:
7.2 Configuring the Task Station

In order for users to handle Back Office processes using the Task Station, it must be configured
according to the job responsibilities of Back Office users. This is also where a user can customize the
items displayed. The Task Engine should be running in the background in order to process tasks.
Should any user require the Kick off / Cut Off functionality of the workflow to work or if they wish to
disperse the responsibilities of users by defining the priority levels, it can be configured.
The Task Engine should be running in the background in order to process tasks. Unlike other Calypso
Engines that need to subscribe to certain events, the Task Engine does not require any event
configuration/subscription.
Access
To access the Task Station, go to Main Entry and click the Operations button.
You can also access the User Task Station Defaults by navigating to:
Main Entry > Configuration > User Access Control > Task Station Defaults
In order to begin using the Task Station, configure the following:

• Set User
206
Notes:
• Task Access Configuration
• User Config/User Preference
Determine User
To select the users whose tasks you would like to configure/display, use the Configure Menu on the
top left of the Task Station and open the ‘Set User’ Window. The ‘Select Users’ window will open.
The list of users provided in the left are the users set up in the system using the ‘Users’ Panel in
the Access Permission.
You will need to move the user that you are configuring from left to right before applying the ‘OK’
button.
Define Task Access for Group

In order to access tasks in the Task Station, the Calypso user needs to belong to a user group
authorized to view/modify the displayed tasks. This is done within the Access Permissions Window
via the Group Access Tab.
By defining Task Access (as per the below example) in the Task Access Configuration window, the
system allows you to configure which tasks users within a group can have access to.
207
Notes:
2 3 4
Shows
the
current
logged in
user and
their
group.
6 5
1. Using the drop down under ‘Group,’ select the access group the user belongs to
2. Select the ‘Event’ that the user can view in the Task Station. All of the Events (user defined and
system) are listed in the window under the ‘Event’ title
Choose the events for the group. You can either:
Scroll down the list of events and highlight the relevant events
OR
Click on the ‘Select All’ button (this will select all the events in the window below). You can
alternatively check the ‘All’ checkbox and unselect the users you do not wish to give access to. You
can deselect all by clicking on the ‘Clear’ button
3. Select the Trading books that the user may view in the Task Station. All the Trading books (user
defined) are listed in the window under the ‘Books’ title
4. In the same way as Events, choose the books for the group. All the book attributes (user defined &
system) are listed in the window under the ‘Book Attrs’ title
In the same way as Events and Books, you can choose the book attributes for the group.
5. Once you have made your choices/restrictions for the user within a group to view (A group user will
only have access to the Events and Books selected), click the ‘Save’ button
208
Notes:
6. If you already have configuration set up for a particular group and you would like to view or make
amendments for the user logged in, you can select the group name (via the drop down mentioned in
point ‘1’ earlier) and then select the ‘Load’ button
Define User Configuration

Once you have specified the user (via ‘Set User’), and determined which Events/Books and Book
attributes the group of the user has access to (via ‘Task Access Config’), you can now specify in detail
how tasks will be organized and viewed within the Task Station for a particular user or group.
Using the Configure Menu on the top left of the Task Station, open the ‘User Config’ Window.
Generic Ways of Configuring the Task Station Blotter

There are multiple ways to configure the Task Station. Users can:
• Use the Calypso out-of-the-box configuration
• Configure a brand new customized configuration
• Duplicate the configuration of a particular user to another user (in the same group)
• Duplicate the configuration of a particular user to another user (in a different group)
• Duplicate a user’s configuration in one group to apply across ‘ALL’ users (in another group)
Calypso Out-Of-The-Box Configuration

Assuming there is not an existing configuration for a particular user, configure the Task Station using
the Calypso out-of-the-box configuration.
1. Click on the button ‘New’
2. Using the dropdown of the ‘User Name’ field, select the user which yet does not have a
configuration and for which you want to configure the Task Station user config
Group book access permissions (defined in the Access Permission Eindow ‘Group Access’
Panel) and Trading Book access permission (defined in the Access Permission window ‘Book
Access’ should be taken into consideration when making choices in this window. An example: if
the book attributes selected are not part of the attributes for which access has been given at the
book level, then group will not be able to see this in the Task Station.
209
Notes:
2 5
4 3
6 1
Configure a New Customized Configuration

3. Click on the ‘Make Default Tabs’ button. This will fill the ‘List of Defined Tabs.’ This field
contains the tab names preconfigured by Calypso. They represent the tabs which will appear in the
Task Station
Each row (in the above case: Trades, Message, Payments, Exceptions) within the ‘List of
Defined Tabs’ tabs represents a tab in the Task Station.
Each tab:
• Derives its name from the ‘Tab Name’ section to the left.
• Represents an Event Class (defaults being Trade (events related to trades), Transfer
(events related to transfers), Message (events related to Messages) & Exceptions
(exceptions generated by the system).
• Has specifically defined Event Types (in accordance with the Event Class).
4. Click on the ‘Save’ button to save your configuration.
210
Notes:
5. The configuration name appears in the ‘Config Name’ field at top right. This is the name that will
appear as part of the choices for your default Config (Configure > Set Default Config).
6. If you do not want to use this configuration, select the ‘Delete’ button.
For a new configuration:

1. Click on the ‘New’ button
2. When the Config window is cleared, using the ‘User Name’ drop down section select the user for
which you want to configure your Task Station
This allows users to customize their Task Station as per the user’s needs.
211
Notes:
3. In the ‘Event Class’ field select the Event Class (defaults being Trade/Transfer/Message &
Exceptions) for which you want your user to have access
4. Click on the ellipses icon under ‘Event Types’ to select the desired Event types you
would like configured for the user in a specific tab
Using the search window

or by scrolling down,
select the relevant Event
Types for the user to
view in a specific tab.
This list on the left of the Event Type selection window will come from the predefined list you have
chosen during the Task Access Configuration section. Now:
1. Event types selected will show in the bottom window of the User Config window
2. Using the ‘Tab Name’ define (this is free format) a name for the tab (this is what will show as the
tab name in the Task Station) that will represent the Event types configured
3. Click the arrow pointing to the right (left serves to move tabs out of the ‘List of Defined Tabs’)
‘Up’ and ‘Down’

4 buttons serve to
move tabs (should
you have more
3 than one) up and
down the window
to adjust order in
which tabs in the
Task Station.
4. The defined name under ‘Tab Name’ (in this case ‘Verified Trades’) will move to the ‘List of Defined
Tabs’ window
212
Notes:
5. Users can use either the ‘Save’ or the ‘Save as New’ buttons to save the configuration. Both cases
will prompt the system to ask for a configuration name
6. Save your configuration giving user name ‘Default Calypso_User’
7. This name is what appears in the ‘Config Name’ field at top right of the User Config window. It is also
what will appear as part of the choices for your default Config (Configure > Set Default
Config)
As before, if you do not want to use this user configuration use the ‘Delete’ button
Duplicate the configuration of one user to another user in the same group
1. Open the User Config window and select the ‘New’ button
2. Open the User Config window and select the ‘Duplicate To User’ button
3. This opens up the ‘Select Source User’ pop up. Identify the user from which you will like to
duplicate
213
Notes:
4. Once you have identified the source, the system will prompt you to ‘Select Source Name.’ Users
can have more than one Source Name
The Source Name corresponds with the Config Name (top right of the User Config window). If
originating user has more than one Config Name, you will have to pick the one that you want
to copy
5. Once Source Name has been selected, the system will prompt you to select the destination user
214
Notes:
6. When the destination user has been selected, the system will inquire if all columns of the originating
user should be copied. When you select ‘Yes to All,’ the system will have saved you an exact
duplication from one user to another
As before, if you do not want to use this user configuration and would like to get rid of it, use
the ‘Delete’ button, which is at the bottom left of the User Config window
Duplicate the configuration of one user to another user in a different group.
1. Open the User Config window and select the ‘New’ button
2. When the User Config window has loaded blank, select the ‘Duplicate To User’ button
3. This opens up the ‘Select Source User’ pop up. Identify the user from which you will like to
duplicate
4. The Source Name selection window will open asking you to select the Config Name you would
like to copy
215
Notes:
The Source Name corresponds with the Config Name (top right of the User Config window). If
originating user has more than one Config Name, you will have to pick the one that you want
to copy.
5. Once source name has been selected, the system will prompt you to select the ‘Destination
User’ which in this case is a user in a different group
6. When the destination user has been selected, the system will inquire if for the new user, all columns
of the originating user should be copied. When you select ‘Yes to All,’ the system will have saved
you an exact duplication from one user to another
Once the configuration of one user in one group has been copied over to be the configuration
of another user in another group for the destination user, Calypso will create an additional
‘Config Name’ representing the configuration that was copied over from the source.
The destination user will have its own original user configuration under its original ‘Config
Name’ (which was what was setup during example ‘C’ earlier) and also a second
configuration where he will have the newly copied configuration under the originators ‘Config
Name.’
216
Notes:
the ‘Delete’ button bottom left of the User Config window.
Duplicate the configuration from one user (in a specific group) to config of users of an
entire group
All users within a different group will have the same new configuration adopted from user in a different
group.
1. Open the User Config Window and select the ‘New’ button
2. When the User Config Window has loaded blank, select ‘Duplicate Group’ button and select the
source user
When ta/Middle Office user1is chosen, it means that this user in a specific group (ta/Middle
Office) will be the source for duplicating to other users in a different group.
217
Notes:
The window will open asking you to ‘Select Source Name.’ The Source Name corresponds
with the Configuration Name (‘Config Name’ top right of the User Config window).
If user has more than one Config Name, select the relevant Config you would like to duplicate
across to other users in a different group.
3. Select the group into which you would like the configuration to be copied into
This means that the configuration of source user ta/Middle Office user1 will be copied over to
the configuration of every user in another group. Select calypso_group and click ‘OK’.
218
Notes:
4. When the destination group has been selected, the system will inquire if you want all columns of the
originating group copied
When you select ‘Yes to All,’ the system will have saved you an exact duplication from one
user (in a particular group) into another group thus applying to all users in that group.
5. The result of this is that the user in calypso_group (Calypso_user and test user) will have their user
configurations overridden with the new config of ta/Middle Office
You will see this by selecting the user using the ‘User Name’ field (ie. test user) and click the
‘Load,’ the system will give you the config of ta/Middle Office user.
the ‘Delete’ button bottom left of the User Config window.
219
Notes:
Load existing configurations
1. Using the User Name field, select the user for which you want to duplicate configuration for
1 2
2. For the user selected in ‘User Name,’ click the ‘Load’ button and if there are existing configurations
for the user, the system will open a window from which you can choose the configuration desired
Config Name is also the name which appears as part of the choices for your default Config
(Configure > Set Default Config).
If user has more than one Config Name, you will have to pick the one that you want to view.
220
Notes:
Filtering Possibilities for User Configuration

Using the User Config window, users can continue to personalize and determine theirs (or their
group’s) Task Station output at a more granular level by the addition of various filtering methods
provided. Below short descriptions for additional ways in which a user can go further define what
his/her Task Station displays.
Set Filter on Tabs
2
3
1. Filter: Allows you to select a filter set to filter trades, transfers, and messages to be displayed in the
Task Station
Filter sets are created using Main Entry > Configuration > Filters > Filter Set.
By default if there is a filter set defined for the user, the system will take it into account
when loading the Task Station for the user. You can set the environment property
CHECK_FILTER_SET_WHEN_LOADING to N to ignore. This filter set when loading
trades, messages and transfers in the Task Station. Default is ‘Y.’
2. Books: You can determine the books for which you want to load tasks for. This is if your access
permission permits
3. Book Attrs: You can select book attributes' values to filter the tasks related to the corresponding
books only. This is if your access permissions permit
4. From/To: For each tab in the ‘List of Defined Tabs’ you can define a specific start and end dates
4
Click the ellipses icon
to change the from
and/or to dates.
The default options will

be available via the
‘Select a Date Type’
window.
221
Notes:
You can also create any relative date in the

domain “taskStationDates” class.
These dates are relative to the Task Station’s start and end dates or to Today (Task Station window
shows them as From/To fields).
They default to ‘START’ and ‘END’ (Task Station start and end dates), but you can set each date to
any date relative to the Task Station dates. For example, the Task Station start and end dates are
both set to Today, but in the Messages tab, you want to see messages generated between Yesterday
and Today. This would be Today -1 (today being 0).
In such a case you would set the start date for the Messages tab to “Task Station start date – 1 day.”
5. SD Filter: Using the search icon for each tab in the ‘List of Defined Tabs,’ you can assign a
Static Data filter that has a task related criteria
6. Internal Reference: This functionality gives users an additional ability to filter the tasks they want
to see in their Task Station tabs. This is based on criterias that are not attached necessarily to the
task itself. Using defined Static Data filters which are not stocked originally on the task, users have
the possibility to filter the type of tasks they would like to view in their Task Station
Example: Imagine that a user only wants to perform tasks that are related to trades that have
been booked by a specific trader or trades that are CLS related.
Using the Internal Reference functionality, users can do this. Prior Static Data filter setup is
required for Internal Reference configuration.
If you do not have a prior configuration, you can use the below example as reference.
Navigate to:
Main Entry> Configuration > Workflow > Task Internal Reference
1. Click ‘Add’ to add an internal reference, and select an event class

(Trade/Transfer/Message/Exception). A line will be added in the bottom portion of the window
222
Notes:
• If you already have a Static Data Filter configuration, click in the ‘SD Filter’ column to
select your static data from the list of Static Data in the Static Data filter window
• Otherwise, click the ‘Add SD Filter’ button in the Internal Reference Configuration window. The
below two screenshots show our Static data filter examples
223
Notes:
We have two Static

Data filters
configured, one
which filters a
particular trader
(Trader X) thus all
trades that are
OR conducted with this
trader, and the other
filters trades that are
flagged to be clearing
in ‘CLS.’ This is a
trade attribute.
• In ‘Value’ column enter a reference value – this is free format (this name appears when the ‘Select’
button is clicked in the Task Station’s User Config). Then click ‘Save’
Once Internal Configuration is in place, back in the User Config window of the Task Station, users can
select a tab and add their desired internal references for the selected event class.
224
Notes:
Once selection is in the Internal

Reference field, use the right arrow
Click the ‘Select’ to add it the right window.
button in the
User Config
under Internal
Reference to
access the
available
configuration.
For the example above, the Task Station of this user (BO User1), the VERIFIED_TRADES
tab will filter trades in VERIFIED status, which have been input by Trader X.
The internal reference will be automatically set on the tasks upon their creation and this can
be viewed in the column ‘Task Internal Reference’ in the Task Station.
225
Notes:
Define Priorities
For the tasks that users will view in their Task Station, Calypso allows prioritization. There are three
levels of priorities: LOW, NORMAL and HIGH.
Priority at the Task level

Using Static Data filters (based on user configuration), the system moves tasks automatically from
one priority level to another. This means that users can define which priority level tasks belong to and
when their priority level changes.
The Task Engine needs to be running so the system determines when a task needs to move to
another priority level.
Main Entry > Configuration > Workflow > Task Priority
2 3
Column ‘Initial Priority’ is considered to

be priority ‘Low.’
1. Click ‘Add’ to add a task priority

2. Under ‘Event Class’ select an event class (Trade, Transfer, etc.) for which a priority configuration
needs to be defined
3. If you already have a Static Data Filter configuration, click in the ‘SD Filter’ column to
select your static data filter from the list in the Static Data filter window
226
Notes:
Otherwise, click the ‘Add SD Filter’ button at the bottom of the Task Priority Configuration
Window. The two screenshots below show a few Static data filter examples.
We have set up Static Data

filter for the Events
VERIFIED_PAYMENT and
VERIFIED_RECEIPT. These
events originate from
transfers.
4. Set the ‘Date Type’ to Creation Date. This refers to the creation date of the event
5. Via both column ‘Time to 2. NORMAL’ and ‘Time to 3. HIGH’ using the Task Priority Times
details input window (shown below), users can set the times after which the task moves from one
priority to the next
227
Notes:
Above shows that the tasks that either VERIFIED_PAYMENT or VERIFEID_RECIEPT will
initially be in LOW category.
After one hour, the Task Engine will move them to NORMAL category and after 2 hours, they
will move HIGH. This adheres to the set holidays and date roll.
6. Click on ‘Apply’ when done. Once back in the main Task Priority Configuration window, apply the
‘Refresh’ button before clicking the ‘Save’ button
In addition to Static Data filters, users can also use Internal Reference to filter and determine at a
higher level of detail for tasks that they want to apply the priority configuration on.
User Priority At The Tab Level

In the User Config window, using the button ‘Priority’ for each tab can to determine the priority of the
tasks visible to the user. In using this option, it is possible to determine which users have which
priority level of tasks they can monitor or work on.
For example, if a user only needs to monitor certain types of transfers that are in one priority and not
another, this can be done by using the ‘Priority’ button. Now, assuming we have BO User1 only
monitoring cash transfers in both priority LOW and NORMAL, only BO User2 needs to work on these
cash transfers once they get to HIGH. You would configure the following:
228
Notes:
1. Load the BO User1 ‘User Config’ window and highlight their VERIFIED_CASH Tab
2. When the ‘Select Priorities’ window opens, select the priority level that the user can work on in
their VERIFIED_CASH Tab
229
Notes:
3. Select ‘OK,’ and save the User Config

4. Load the BO User2 ‘User Config’ window and highlight their VERIFIED_CASH Tab
230
Notes:
5. Select ‘OK,’ and save the User Config
This means that should there be any VERIFIED_PAYMENT or VERIFIED_RECIEPT transfers in

LOW or NORMAL priority, BO User1 will be able to view and work on them. If there are any
VERIFEID_PAYMENT or VERIFIED_RECIEPT HIGH priorities, these will show in BO User2’s
VERIFIED_CASH tab and he/she can work on them.
Determine Colors
Calypso provides default out-of-the-box color-coding by tasks.
• Red is predefined to indicate a high priority task (the level of priority is set by the user on a task-
by-task basis), or an overdue task that has not been handled by its cut-off date
• Blue is predefined to indicate a task under processing
• Gray background is predefined to indicate a completed task
• Purple is predefined to indicates a task that has been assigned to another user
In addition, users can highlight tasks that are pertinent to them in a more customized manner by using
the Task Station’s color-coding selection capabilities. Calypso offers two different ways to define
colors on tasks.
Defining Colors via User Config

To define colors:
1. Load a specific user and select a specific tab in ‘List of Defined tabs’
231
Notes:
2. Determine the relevant ‘Event Type’ for which you would like to define a color
3. Click ‘Set’ to select a color for this event type in the VERIFIED_MESSAGE tab and click ‘OK’
232
Notes:
Pick a color
from the color
selection
window when
done.
4. ‘Save’ the User Config
When the Task Station is reloaded, the corresponding events will be displayed in the selected
color in the Task Station.
Defining Colors via Set Color

To define colors for specific Events via the ‘Set Color’ menu:
1. Select the ‘Set Color’ Menu in Task Station > Configure Menu
233
Notes:
2. The ‘Color Dialog’ box opens allowing you to select a color for a specific Static Data filter
3. The ‘Color Dialog’ box opens, allowing you to ‘Add’ your configuration
4. Using the ellipses button under the ‘Color’ column, determine the color you would like to apply
234
Notes:
4 5
5. Use the drop down next to ‘Static Data’ column to apply the color to a specific task related Static
Data
6. Once you have completed your configuration, click on the ‘Apply’ button of the Color dialog box
7. When you reload the Task Station, you will see that the color for the relevant event has changed to
your selected color
The color configuration set using the ‘Set Color’ option will override the user configuration
that is in place for all users
235
Notes:
7.3 Defined Configuration for our Users

Whether by using the Calypso default out-of-the-box Task Station configuration or by using any of the
other methods described for configuration, users can begin to use the Task Station. In previous
scenarios, we have created user setups to address each of their ‘hypothetical’ responsibilities. We will
use them and their daily tasks to go through the functionalities of the Task Station.
From the total list of users we had set up and discussed, the following example users have had
relevant configuration put in place. For this next section, keep in mind our original Workflow and
scenarios discussed while covering Workflow tasks and STP.
Original Workflow
Resulting
Original Status Action Task STP Rules Users/Executors
Status
PENDING_ORD CONFIRM_ORD
CheckLegalAgreement/Ch
PRICING
ER ER Yes Yes eckSDI System
CONFIRM_ORD
ER MO_AMEND PENDING ta/Middle Office
PENDING
AUTHORIZE VERIFIED Yes Yes Cpty NOT Chase System
Original Scenario
A trade was transacted with Chase:
• The trade having passed the first STP (CheckLegalAgreement) arrived at resulting status
CONFIRM_ORDER
• The ta/Middle Office, once having confirmed with the correct parties, has a task to transact
manually. This is the application of the workflow action MO_AMEND
A trade was transacted with BK XYZ:

st
• The trade (due to lack of LegalAgreement between PO and Counterparty BK XYZ) broke the 1
STP rule
• The trade is held at status PRICING
ta /middle office user 1

This user represents the trading assistant/middle office user who confirms trades transacted by
traders, thus validating them and pushing them down their lifeline to generate the back office
components. This begins the component’s operational processes.
In a previous scenario, we had reviewed a case where the ta/Middle Office user (being in a different
group from the operational user) made changes and the changes were setup (using workflow) to be
accepted or rejected.
In addition to amending trades once they have been confirmed and in the ‘back office’ operational
chain with the ta/Middle Office user, while confirming trades transacted by trader’s activities, could
need to cancel a trade. Some reasons for this could be that, although an order was input, the trade
was not finally transacted and not eligible or that it was input by error. To accommodate for this, we
236
Notes:
have added a transition for the ta/Middle Office user to be able to cancel a trade before back office
components are generated and confirmations sent out.
Regardless, whether to monitor the trades that have been executed by front office users, apply
manual tasks required (as per workflow) to approve/confirm trades downstream or to cancel
transactions and/or take care of any STP tasks that have failed the process, the ta/Middle Office user
will need to use the Task Station.
As a consequence, remembering the scenarios that have transpired already (discussed in our earlier
module), we will go over the ta/Middle Office setup reviewing at each point where in the workflow
his/her role comes into play and how they go about transacting their required activities.
Original Resulting Users/Exec Access

Action Task STP Rule
Status Status utors Perms
NONE NEW PRICING Yes Trader Trader

CheckLegalA
PENDING_O CONFIRM_O
PRICING Yes Yes greement/C System
RDER RDER
heckSDI
CONFIRM_O MO_AMEN ta/Middle ta/Middle
PENDING
RDER D Office Office
Cpty NOT
Chase
Assuming the ta/Front Office needs to cancel the trade:

Original Resulting Access
Action Task STP Rules Users/Executors
Status Status Perms
MO_CANC ta/Middle
PENDING CANCELED Trader
EL Office
Assuming the ta/Front Office needs to change details of the trade:
Original Resulting Users/Exec Access

Action Task STP Rule
Status Status utors Perms
ta/Middle ta/Middle
VERIFIED NEW PRICING Yes
Office Office
CheckNoCH Bo ops
FO_AMEND BO_AMEND VERIFED Bo ops
ange user 1 or 2
Bo ops
FO_AMEND REJECT VERIFIED Bo ops
user 1 or 2
237
Notes:
The Books for which ta/Middle Office

has access to has been limited to
Equity Trading Book and OTC Trading
Book according to his/her access
permissions.
We have created a tab named

VALIDATE_TRADE and assigned the
Event Type
CONFIRM_ORDER_TRADE. This is a
manual transaction ta/Middle Office
will conduct after confirming trade
details with relevant parties.
Note: User needs to have access perm

for the action to Confirm trade by
applying MO_AMEND on trade.

CONFIRM_TRADE and assigned the
Event type VERIFIED_TRADE as this
means one of two things for this user:
a) Trades have been confirmed

and now pushed to the back
office for processing.
b) Should some detail of the

trade need to be amended
after it has been confirmed,
they will be seeking out this
trade to amend from this list
of VERIFIED trades. Note:
User needs to have access
perm for the action
BO_AMEND trade.
238
Notes:

STP_BREAK and assigned the Event
Types PENDING_TRADE and
PRICING_TRADE because
according to the workflow, in the
event that either of the STP rules
setup (CheckLegalAgreement
,CheckSDI or Cpty NOT Chase)
breaks, then the ta/Middle Office
needs to investigate trade, make
amendments and make sure the
trade is confirmed and moved down
to back office.

EXCEPTIONS with Event Types
EX_STATIC_DATA so that the
ta/Middle Office could be alerted
of breaks and issues that arise
from some static data missing (i.e.,
missing Legal Agreement or no
Contact defined for
Counterparty).
The exceptions configured should

for the large part correlate with
the STP breaks.
calypso_bo operations user 1

This user is part of the ‘operational’ group and has access rights to monitor (via Task Station) or
modify the daily Back Office tasks across all processing organizations, books, products, etc.
In the case below, transaction is in place to allow BO User1 to participate in both ‘Different User’ and
‘Manual Authorization’ scenarios. Displayed is a table showing how his/her particular role comes into
play.
Diff
Original Resulting
Action Task STP User/Manual Rules Users/Executors
Status Status
Auth
PENDING_O CONFIRM CheckLegalAgree

PRICING
RDER _ORDER Yes Yes ment/CheckSDI
CONFIRM_
ORDER MO_AMEND PENDING ta/Middle Office
PENDING AUTHORIZE VERIFIED Yes Yes Cpty NOT Chase
239
Notes:
Assuming the BO User 1 needs to make a change or update the trade (apply BO_AMEND)
Diff
Original Resulting Tas ST Users/E Access
Action User/Manual Rules
Status Status k P xecutors Perms
Auth
PENDING
BO_AME Bo ops
VERIFIED _FO_AME Yes YES Bo/ops
ND user 1
ND
Front Office informs BO User 1 to make a update the trade (apply BO_AMEND).
Diff
Auth
FO_AME Ye CheckPendingMo Bo ops

VERIFIED VERIFIED Yes YES Bo/ops
ND s difications user 1
According to the access perm rights, BO

User1 has been given access to view all
tasks related to all PO/books.

VERIFIED_TRADE and assigned the Event
Type VERIFIED_TRADE. This will enable
the BO User to:
a) View the confirmed trades
coming in from the front office/ta.
b) Apply action BO_AMEND for

the ‘Different User’ scenario
where he/she needs to amend
trade and action FO_AMEND for
‘Manual Authorization’ cases
where he / she has been asked to
amend trade.
Note: User needs to have access perm to

apply action BO_AMEND and
FO_AMEND on trade.
For BO User in ‘Different User’ scenario, once changes are made and accepted, then trade will have
a resulting status ‘VERIFIED.’ Approver could put a comment stating approval. If rejected the resulting
status is again ‘VERIFIED’ (approver could put a comment stating reason of rejection) and BO User
has opportunity to make appropriate amendments to be accepted.
240
Notes:

TRADES_WAITING_APPROVAL/REJE
CTION and assigned the Event Type
PENDING_FO_AMEND_TRADE. This
will enable the BO User to:
View the trades that user has applied

BO_AMEND action. This is only to
view the changes applied using the
‘Different User’ Scenario and that are
waiting acceptance/rejection from
another user.

VERIFID_CASH and assigned the
Event Type
VERIFIED_PAYMENT and
VERIFIED_RECEIPT.
There is also corresponding tab

named SETTLED_CASH showing
SETTLED_PAYMENT and
SETTLED_RECEIPT.
These two tabs will serve the BO

User1 to monitor the cash
transitions related to the trades
(in our case Swap) move along
their lifecycle through to
SETTLED without breaking.

VERIFIED_SECURITY and assigned
the Event Type
VERIFIED_SEC_DELIVERY and
VERIFIED_SEC_RECEIPT.

named SETTLED_SECURITY
showing
SETTLED__SEC_DELIVERY and
SETTLED_SEC_RECEIPT
These two tabs will allow the BO

User1 to monitor the security
transfers related to the trades (in
our case Equity) that move along
their lifecycle through to SETTLED
without breaking.
241
Notes:

VERIFIED_MESSAGE and assigned
the Event Types
VERIFIED_CONFIRM
VERIFIED_PAYMENTMSG
VERIFIED_PAYMENT_ADVICE
VERIFIED_SEC_DELIVERY
VERIFIED_SEC_RECEIPTMSG
VERIFIED_RECEIPTMSG.

named SENT_MESSAGE with the
same Event types as above, except
they are in SETTLED_ prefix.
These two tabs will serve the BO User1 as a means to monitor the messages related to the trade and
its related cash and/or securities. These are the messages generated and later sent out to the
relevant corresponding parties (Counterparties, Agents, etc.) without breaking any rules.

INVALID_TRANSFER and
assigned the Event Types
INVALID_PAYMENT
INVALID_RECEIPT
INVALID_SEC_DELIVERY
INVALID_SEC_RECEIPT
Should transfers be in Invalid

Status (i.e. be generated
without any transfer rules
attached) this tab will identify
and display those transfers.
We have created a tab

named EXCEPTIONS where
a few Event Types for a
generic BO User have been
listed.
Information on some of the
exceptions has been listed in
the table below.
242
Notes:
Exception Type Code Description Generating Engine
EX_STATIC_DATA Some Static Data is missing Transfer Engine

(legal agreement/LE Contact
Workflow Rules
info for a Cpty.).
EX_MISSING_SDI Transfer Engine cannot find Transfer Engine

SDI’s to attach to Transfers.
EX_ADVICE_SETUP Advice Setup is not correct Message Engine

to produce an advice.
EX_LEGAL_ENTITY_ROLE Exception to signal that a Message Engine

Legal Entity could not be
found for a specific role.
EX_GENERATING_CASHFLOW Cashflows associated to a Transfer Engine

trade cannot be generated
or the number of cashflows
does not correspond to the
number of transfers
generated.
EX_GENERATING_TRANSFER Unable to generate transfers Transfer Engine

from trade.
EX_DUPLICATE_PAYMENT Generated when an existing Transfer Engine

Transfer cannot be
CANCELED and replaced.
EX_PRICE_FIXING
EX_RATE_RESET If Rate Resets cannot be Scheduled Task

generated. EOD process RATE_RESET
fails.
EX_OUTDATED_TASK A user had not completed Task Engine

task when task’s cutoff date
was reached and is no
longer eligible for
completion.
EX_OUTDATED_TRADE When task is not applicable Task Engine

EX_OUTDATED_MESSAGE after the cutoff date. Split
into 3 exceptions based on
EX_ OUTDATED_TRANSFER
task object processed.
calypso_bo operations user 2

This user, just as calypso_bo operations user 1, is part of the ‘operational’ group. His/her rights are
the same as user 1 (so in essence this user can have the same tabs as user 1), a distinction has
been made between the two as this user has been given the additional role of acting as the approver
of any changes user 1 makes.
243
Notes:
In the case where workflow and authorization are required between groups, approval/rejection is
dependent on ‘Groups’ workflow access permission, i.e. where the ta/Middle Office user makes
changes and a different group approves/rejects. BO User1 or BO User2 can essentially make the
approval/rejection.
In the table below, we have added this portion of the breakdown against the user. This is only
because BO User2 has been given approval/rejection responsibility over his/her peer BO User1
during the ‘Different User’ and ‘Manual Authorization’ scenarios. Technically speaking, it means BO
User1 or BO User2 could be the approver or rejecter of ta/Middle Office changes.
Diff
Auth
PENDING CONFIRM Ye CheckLegalAgree

PRICING Yes System
_ORDER _ORDER s ment/CheckSDI
CONFIRM MO_AME ta/Middle ta/Middle

PENDING
_ORDER ND Office Office
Ye
VERIFIED Yes Cpty NOT Chase System
s
Different User: BO User1 makes changes to the trade (BO_AMEND) and BO User2 accepts
Diff
Auth
PENDING
BO_A
VERIFIED _FO_AME Yes Bo user1 Bo/ops
MEND
ND
PENDING_F BO_A
VERIFIED Yes CheckNoChange Bo user2 Bo/ops
O_AMEND MEND
PENDING_F REJEC
VERIFIED reject Bo user2 Bo/ops
O_AMEND T
Ta/Front Office requests that BO User1 updates trade applies FO_AMEND).
Diff
Auth
PENDING
EX_TRAD Accept/Re
_FO_AME Yes Bo user2 Bo/ops
E_AUTH ject
ND
244
Notes:
Assuming ta/Front Office needs to update the trade:
Diff
Auth
PENDING
BO_A Ta/Middl Ta/Middl
VERIFIED _FO_AME Yes
MEND e Office e Office
ND
PENDING_F BO_A
VERIFIED CheckNoChange Bo user1 Bo/ops
O_AMEND MEND
PENDING_F REJEC
O_AMEND T
This BO User2 has been given the

same rights as BO User1 and has
the same tabs configured as his
colleague BO User1. The only
differentiation between these users
is BO User2 is implicated in the 4-
eye principle on BO User 1. In
place of tab named
TRADES_WAITING_APPROVAL/
REJECTION like his colleague BO
User 1.
BO User2 has tab

TRADES_APPROVAL/REJECT and
TRADES_MAN/AUTH_APPROVA
L/REJCT where the two have
different Event Classes and Event
Types:
EX_TRADE_AUTH and
PENDING_FO_AMEND_TRADE
have been configured. This is to
allow for ‘Different User’ scenario,
Manual Authorization’ scenario and
‘Access permission with &
workflow’ scenario.
a) View the trades that user

has applied FO_AMEND
action on (in Different
User Scenario) and that
are waiting
acceptance/reject of
another user.
245
Notes:
calypso_bo management user 1

In this scenario, the role of this user is two-fold. As discussed, when setting up this user during our
Access Permission section, this user acts as a doer and also an overseer/manager across several
groups. He/she, being part of the Ops management group, has access to view/modify/authorize
operational processing across all Processing Organizations/books/products.
This is more of senior management role, where the user has access to block/unblock and reinitiate
processes where other employees cannot. As well as having some of the tabs the other users (BO
User1, BO User2) have, this user has a few specialized tabs.
This user in the Management

team has tab named
HANGING_FRONT_TRAD
ES where Event Types
PENDING_TRADE and
PRICING_TRADE have been
listed.
This allows a user to see

which trades have been
stopped by the STP process.
To determine fixes should
they need to intervene or
assign correct people to
ensure from a back office
perspective, all requirements
are in place.
Tab
WAITING_TA_VALIDATI
ON tab allows user to
survey the trades coming
from the front office which
have not yet been confirmed
and sent to the back office.
Event Class:
CONFIRM_ORDER_TRAD
E has been setup as the
trades not confirmed by TA
would be in status
CONFIRM_ORDER.
246
Notes:
Tab VALIDATED_TRADES has

been setup to view trades that
have been sent to Back Office
operations (Event Type
VERFIED_TRADE selected),
which have had their relevant
back office components
generated and unless they get
amended, should follow their
lifecycle according to their
individual product lifecycles.
Tab BO1_AMENDED_TRADES
with Event Type
PENDING_FO_AMEND_TRAD
E allows the manager to survey
the trades the BO User1 has
changed and waiting on action
on.
Tab
BO2_TRADE_ACCEPT/REJECT
with Event Type
PENDING_FO_AMEND_TRADE
allows the manager to survey the
trades the BO User2 needs to
Accept or Reject.
247
Notes:
Tab
BO2_TRADE_MAN/AUTH
with Event Type
EX_TRADE_AUTH also
allows the manager to survey
the trades the BO User2
needs to Accept or Reject.
For our scenarios, the following users do not have any setup configured. The reason for which has
been listed below against each user.
trader x
Setup has not been configured for this user as it is not business practice for Front Office users to
have access to the Task Station. Their job functionality does not require them to monitor exceptions,
meaning this user will not require setup. Front Office users use the Trade Blotter and Calypso
Workstation to be alerted of specific trade status.
calypso_bo_eod marks user 1

We are assuming that the job functionality of this user is predominantly EOD Market Data/Curve
maintenance. Although this user could monitor exceptions generated by an EOD Scheduled Task
failing (due to lack of/missing data), at this point we have esteemed setup not to be necessary.
calypso_bo_accounting user 1
The Task Station can be used by the Accounting Department to monitor a range of exceptions related
to accounting. These could be information on missing accounting data or logs related to accounting
related Scheduled Tasks. For our course purposes of aligning the Workflow configuration and
monitoring trades/transfers and messages, at this point we have determined this setup not to be
necessary.
Further information on ‘exceptions’ related to accounting are covered both as part of

Calypso Documentation and the Fundamentals of Calypso Accounting course.
248
Notes:
7.4 User Scenarios

Handling Tasks
This section provides details on how users would use the Task Station to perform their duties.
During the Workflow module and again mentioned above, we have discussed a couple of trades
passing and breaking the STP transactions before the trades were confirmed by the ta/Middle Office
user and pushed down for ‘Back Office’ processing.
Recalling the trade events:
Swap/Equity Trade 1:
A trade was transacted between PO (CUB) and Chase NY
• The trade passed first STP rule (CheckLegalAgreement)
• The trade moved to CONFIRM_ORDER status
Swap/Equity Trade 2:
A trade was transacted between PO (CUB) and BK XYZ
• The trade did not pass the first STP rule (CheckLegalAgreement)
• The trade was stuck in PRICING
Now, with the relevant setups in place, users would conduct the following steps to see their
tasks/perform actions.
TA Handling Tasks
Ta/Middle Office user would open his/her Task Station and:
1. In the Configure Menu, a user would choose ‘Set User’ to select him/herself as the user that will be
working on the Task Station
2. When the ‘Select Users’ window comes up, the user would select their user name from the list
provided. In this case it is the ta/Middle Office user 1
249
Notes:
3. For the relevant tasks to show, the ‘From’ and ‘To’ range need to be correct
4. Using the Task Station the ta/Middle Office user would apply the ‘Load’ button. This would load the
ta/Middle Office’s configured tabs that we showed earlier
The Task Station table would look like this when there is no activity loaded.
3
4
The configured tabs for

the user appear here.
If few or no tasks appear within your configuration, set the ‘To ‘date field to two or more years into
the future and click Load again.
In the first scenario, keeping in mind the workflow, the trade between Processing Organization and
Counterparty ‘Chase’ had passed the initial STP (the rule ‘CheckLegalAgreement’).
250
Notes:
Original Resulting Users/Exe Access

Action Task STP Rules
Status Status cutors Perms
PENDING_ CONFIRM_ CheckLegalAgreeme

PRICING Yes Yes System
ODER ORDER nt/CheckSDI
CONFIRM_ MO_AMEN Ta/Middle Ta/Middle

PENDING
ORDER D Office Office
AUTHORIZ
PENDING VERIFIED Yes Yes Cpty NOT Chase System
E
Assume ta/Front Office needs to cancel the trade:

MO_AMEN Ta/Middle Ta/Middle

PENDING CANCELED Yes
D Office Office
Assume the ta/Front Office needs to update the trade:

PENDING_
BO_AMEN Ta/Middle
VERIFIED FO_AMEN Yes Trader
D Office
D
PENDING_
BO_AMEN Bo ops
FO_AMEN VERIFIED CheckNoChange Bo/ops
D user1
D
PENDING_
Bo ops
FO_AMEN REJECT VERIFIED reject Bo/ops
user 1
D
Due to ta/Middle Office Task Station ‘User Config,’ when the user loads his/her Task Station:
Ta/Middle Office user will see a Task in tab ‘VALIDATE_TRADE.’ A task has been created because
the ‘Check task’ checkbox was checked in the PSEventTrade Workflow on the transition:
1. The Trade Object is in CONFIRM_ORDER status

According to the Workflow and Access Permission rights, the ta/Middle Office user will need
to apply the manual action MO_AMEND
251
Notes:
Workflow and/or
exception tasks
appear under each
tab in accordance
with the
configuration defined
for the user using the 2
‘User Config’
window.
The summary panel will show
relevant information for the
task selected/highlighted. In
the above case, the selected
task is related to a trade task,
and the information shown is
that of the trade.
2. The details of the task appear at the bottom because this capability was selected as part of the ‘User
Config’ setup
This checkbox is
checked by default for
each tab listed within
the ‘List of Defined
Tabs’.
This allows users to

see a summary panel
(as above) at the
bottom of the relevant
tab within the Task
Station showing the
details about a
selected task.
In order to ‘own’ the task and transact the manual action, the ta/Middle Office user will:
• Select ‘task’
• Click on ‘Process’
252
Notes:
3. This action indicates that this user now ‘owns’ this task. The task row changes color, e.g., blue
4. Assuming that ta/Middle Office user has confirmed the trade with the relevant parties the user can
perform their manual task of confirming the trade. Using either the ‘Action’ Menu or by right-clicking
on the task row, the ta/Middle Office user can execute their MO_AMEND action
OR
5. As the Counterparty of the Trade is Chase NY, task fails on the next STP action. Trade remains at
PENDING status as the rule requires the counterparty to be different than Chase. The task appears
in the STP_BREAK tab of ta/Middle Office user
The system comment lets

the user know that the
STP break was due to the
rule ‘Cpty NOT Chase’
being broken.
The STP rule being broken creates an Exception.
253
Notes:
Because of the issue, ta/Middle Office needs to investigate.

The ta/Middle Office user can right-click on the task to open the trade in question (straight
from the Task Station) and review the exact details of the trade and investigate with the Front
Office and/ or broker/sales, etc.
6. When investigating, let us assume that the ta/Middle Office user finds out an authorization had not yet
been given to transact with this Counterparty. The ta/Middle Office adds the necessary comment on
trade object and right-clicks on the tasks, then selects ‘Add Generic Comments’
1. When GenericCommentEditor Report comes up, ta/Middle Office user, clicks the button and
adds a comment type (this is optional)
The type is dependent on the organization. It could be ‘formal,’ meaning the organization or
processing departments have defined meanings for comments or it could unofficial
254
Notes:
1
2
2. ta/Middle Office user inserts the relevant comment in the comment field and then adds it to the trade
by clicking on the icon
In the bottom section of the Window, the bottom line is updated with the comment.
3. Using the icon, ta/Middle Office will save the comment to be attached to the underlying trade.
When saved, the system will let the ta/Middle Office user know (via a pop up) that a comment
has been saved.
The Generic Comments functionality adds comments to the underlying Object. If the task
is related to trade, the comment will be on the underlying Trade object If the task is related to
transfer, then to the Underlying Transfer object, etc.
As per the below screenshot, the comment added by the ta/Middle Office user will be visible on the
underlying trade.
255
Notes:
Using the same steps of ‘owning’ the task (described in the last example), the ta/Middle Office user:
• Highlights ‘task’
• Clicks on ‘Process’
• When task color changes, as permitted by workflow



PENDING
AUTHORIZ
E
Assume the ta/Front Office needs to cancel the trade:
256
Notes:

MO_CANC Ta/Middle Ta/Middle

PENDING CANCELED
EL Office Office
With access permissions:

• ta/Middle Office user applies action MO_CANCEL
At this point, we are considering that the trade has not yet been ‘officially’ booked, i.e., it has not been
confirmed for the Back Office to begin processing. The ta/Middle Office can cancel without
authorization because it is assumed to still be in the hands of the Front Office.
The task will disappear from the ta/Middle Office’s tab.
In the second scenario, as there was not a Legal Agreement in place for BK XYZ the trade between
Processing Organization CUB and Counterparty BK XYZ. The trade never passed the initial STP (the
rule ‘CheckLegalAgreement’).
In this next scenario, the ta/Middle Office user (according to their User Config) will see a Task in tab
‘STP_BREAK.’
1. In the Task Station, the ta/Middle Office user would see this trade stuck in PRICING status
2. System comment would show 'legal agreement' missing
257
Notes:
The system comment is applied at the task

level and is derived from the Workflow. It
lets the user know that the STP break was
due to ‘No Agreement being in place.’
As in the previous case, the ta/Middle Office user can pull up the trade via the Task Station
(by right-clicking the task and selecting ‘Trade’). The trade will appear to be stuck in
PRICING.
The ta/Middle Office’s tab ‘EXCEPTIONS’ will also show an EX_STATIC_DATA exception
task.
258
Notes:
If the ta/Middle Office decides to apply next action without investigating, the system will throw an
exception.
At this point, the ta/Middle Office user can see that the trade has not gone through as required and
the reason for it. Ta/Middle Office user will need to investigate the issue.
Here are a few options we will review:
Trade Counterparty for which the trade was booked against could have been wrong.
• In which case, the ta/Middle Office user needs to amend the counterparty and move it to next step
of lifecycle
OR
Trade Counterparty for which the trade was booked is correct and should have been a Legal
Agreement in place.
• In this case, the ta/Middle Office user needs to inform the correct individuals (back office users)
so that static data can be updated and the trade can flow to the next steps of its lifecycle
Assuming the issue was the second one (a Legal Agreement is in place with the Counterparty BK
XYZ), then the correct parties would update the static data for the Counterparty BK XYZ. Once the
ta/Middle Office is informed by the Back Office that the correct static data is in place:
1. ta/Middle Office user needs to manually apply the broken STP transaction. The ta/Middle Office user
would highlight task and to ‘own’ task, clicks the ‘Process’ button
259
Notes:
2. Under the Action Menu, highlight task and apply the next action (PENDING_ORDER) on the
workflow. Thus the trade passes the rule (CheckLegalAgreement)
As shown in the previous case, the user could also right click on the task and apply the
action.
When the PENDING_ORDER action is executed, there is a message pop up letting user
know that trade has been amended.
As per the workflow, access permission rights and the Task Station setup, the trade will move
to its next lifecycle status of CONFIRM_ORDER. The task for the ta/Middle Office user moves
to the VALIDATE_TRADE tab and the STP_BREAK tab has no more breaks.
260
Notes:
In the VALIDATE_TRADE tab of the ta/Middle Office user, the task is present.
If ta/Middle Office user is now ok with the trade, then the task can be confirmed and moved over to
the Back Office.
1. The ta/Middle Office user will highlight the task
2. Click ‘Process’
261
Notes:
3. Via the Action Menu or by right-clicking ‘Apply’ the next action on Workflow ‘MO_AMEND’
4. When action MO_AMEND is applied, to let user know that the action has been applied on trade, the
system will generate another pop up message
5. As per workflow and the Task Station User Config, the trade will move to ‘VERIFIED’ status and is in
the ta/Middle Office’s ‘CONFIRM_TRADE’ tab
Once an action has been applied using the Task Station, the user can click the ‘COMPLETE’ button.
Usually most Actions users perform on a task will complete the task automatically. The task will move to a
COMPLETED status, which usually makes it disappear from the user’s blotter. If a user wishes to view their
completed tasks, they can do so by going to the Configure menu of the Task Station and selecting the
‘Complete’ option.
262
Notes:
The management of tasks can be done via:
Ø The buttons on top of the Task Station blotter:
Ø By right-clicking a task and selecting ‘Apply’ and clicking the relevant action from the list.
Ø By going to the Task Station > Configuration menu and ‘Auto Process’ option for the system to auto
process rather than doing it manually.
Ø By going to the Task Station menu bar and choosing ‘Apply Status,’ then applying the relevant action from
the list.
Assuming at some point in the day the ta/Middle Office user wants to investigate tasks and actions
that took place, they can access the tasks by:
• Right-clicking on the trade task in their Task Station and clicking on Task History
263
Notes:
The Task History window will open allowing user to view all the trade tasks that have been carried out
on the selected trade.
• Right-clicking on the trade task in the BO Browser without going through the Trade
Using the Back Office Browser

A user can access the Back Office Operation windows to confirm if back office components have
generated for this trade and all the tasks that have transpired concerning the trade up until it
reached VERIFIED.
The system creates tasks when:

• A user (the ta the ta/Middle Office user in this case) applies an action due to a manual
transaction.
• There is an STP break
264
Notes:
• The system generates events as an outcome of another event (for which user has set User Config
to be informed)
• The system detects an exception
Each incident creates a new task. The task tab in the BO Browser window shows not only the trade
tasks, but also all the tasks associated with all the other Event Classes. When the task is processed
and actions applied in due time, the system marks it as COMPLETED. A user can view this via the
‘Task’ Tab.
Task Id Status = Point at which task was created (by user or by system).
67553 Task when the trade stopped at status PRICING due to STP break.
67554 Task when an exception was created when STP broke.
67556 Task for the ta to transact a manual workflow action.
67557 When the trade reaches VERIFIED status.
BO User1 Handling Tasks

In the scenario, the role of the BO user1 comes into play once the ta/Middle Office has confirmed the
trade and the trade reaches VERIFIED status.
This does not mean that the Back Office components (transfer/message/postings) have not been
generated. The point (VERIFIED status or other status) in which they get generated is dependent on
configuration.
Transfers: Whether with correct SDI or not will generate when trade is saved. If there is a filter
(VerifiedEventFilter), they just will not generate when the trade’s initial resulting status is either PRICING or
PENDING.
Messages: Will generate at any point on the trades, transfer or other lifecycle event as long as the relevant
engine is running and there is Message Configuration for the PO/Product and relevant Event Type.
Postings: Will generate at any point on the trades, transfer or other lifecycle event (liquidation/Coupon
payment/Rate Reset) as long as the relevant engine is running and there is (in addition to Accounting
Rule/Book etc.) an Accounting Event Configuration for the Product and relevant Event Type.
265
Notes:
Once this happens, we should recap the events that have/should have taken place.
Receipt of Trade Event (PSEventTrade) by the Transfer Engine and combination of
cashflows/security flows with correct SDI rules, have allowed the system to create Transfer rules.
The combination of Event Subscription of Transfer Engine, Transfer rules and Transfer Workflow, the
system has generated the transfers related to the Equity transaction.
With the combination of Event Subscription (PSEventTrade) of the Message Engine/Correct Message
Configuration (for VERIFIED_TRADE) and Contact Setups, the system has generated the trade
related message CONFIRM.
The combination of Event Subscription (PSEventTransfer) of the Message Engine, correct Message
Configuration (for VERIFIED_SEC_RECIEPT), Contact Setups and Transfer object, the system has
generated the transfer related message RECEIPTMSG.
266
Notes:
Combination of Event Subscription of the Accounting Engine (PSEventTrade)/Correct Accounting

Book (CALYPSO UNI BANK)/Accounts/Accounting Event (COT or NOM_FULL dependent on
organization) /Accounting Rule (Equity Trading) setups, the system has generated the trade related
accounting entries.
At the
discretion of
the
organization,
at this point
either off
balance or
non-off
balance
entries can
be generated.
The total tasks concerning the trade are shown below.
When the Back Office User 1 logs into the Task Station, the tasks related to the components
generated should be visible for him/her to work on.
In every case, the actions the user can perform using the Task Station is dependent on the
combination of access permission rights, Task Station ‘Task Access’ configuration, Task Station ‘User
Config’ and Workflow setup.
267
Notes:



PENDING
AUTHORIZ
E
Assume the BO User1 needs to update the trade (apply BO_AMEND):
Original Resulting Diff User/Manual Users/Ex Access

Status Status Auth ecutors Perms
PENDING
VERIFIE BO_AME Bo ops
_FO_AME Yes Bo/ops
D ND User 1
ND
Assume the ta/Front Office informs BO User 1 to update the trade:
Original Resulting Diff User/Manual Users/Ex Access

Status Status Auth ecutors Perms
CheckPen
VERIFIE FO_AME Bo ops
VERIFIED Yes Yes Yes dingModific Bo/ops
D ND User 1
ations
To review some of the activities the BO User1 could perform using his/her Task Station:
BO User1 opens his/her Task Station
1. From the ‘Configure’ Menu, choose ‘Set User’ to set the user that will be working on the Task
Station
2. The From/To dates need to be adjusted accordingly
268
Notes:
3. The ‘Load’ button needs to be clicked

4. The configuration of the Task Station tabs will be adjusted according to the User Config setup
configured for this user
2
3
• The BO User1 will view his/her Task Station updated
To review the scenario where BO User1 needs to make amendments to trades and needs to apply
the four-eye principle.
For this different user scenario, let us assume that:
On the task in VERIFIED_TRADE Tab, BO User1 needs to amend the trader name on the underlying
Trade Object. User would click on ‘Process’ button after selecting the task:
1. Double-click in the ‘User Comment’ column to add a comment on the task to indicate to the
approver (BO User2), the reason for change
269
Notes:
Clicking out of the ‘User Comment’ column, to apply the comment to the task:
2. Right-clicking on task and apply ‘Update Comment’
The user would then need to make the relevant change on trade.
3. Right-click the task and apply the ‘Trade’ Menu to open trade for modifications
The trade will open as per the below screenshot.

4. Via the ‘Details’ tab of the trade Window, BO User1 would change the trader name
270
Notes:
5. Still in the ‘Details’ tab of the trade Window, BO User1 would apply the action on the trade to
BO_AMEND
6. BO User1 will save the trade by applying F5

BO User1 will receive an update (pop up) letting him/her know that trade has been amended.
In the Task Station, BO User1 can see that his/her tab VERIFIED_TRADE no longer has task related
to the above trade but a new update has appeared in the TRADES_WAITING_APPROVAL/REJEC
Tab.
Thus, BO User1 awaits approval/rejection from another user.
271
Notes:
Manual Authorization Scenario

Until the market closes, the course of a normal day would involve traders transacting trades and (in
our scenario) a ta/Middle Office user confirming them before the Back Office starts working on the
various components.
To show how BO User1 can use the Task Station to apply the Manual Authorization functionality, let
us assume on one of the trades done during the day, once the trade has reached VERIFIED status
and BO Operations are working on the components, the ta/Middle Office user contacts the BO User1.
User1 is asked if specific changes/amendments be made on a particular trade that BO Operations is
already working on. For example, let us assume that the change/amendment required is on the
quantity of the trade.
For the sake of being consistent, let us also assume this is an Equity trade, also with Processing Org
CUB vs. BK XYZ.
BO User1 will search for the task of underlying ‘VERIFIED’ trade in VERIFIED_TRADE Tab:
1. BO User1 will right-click the task and select the ‘Trade’ Menu, to open trade for modifications
2. When the trade opens, as requested, BO User1 will change the amount on the trade from 50 to 100
272
Notes:
2
2
3. Using the ‘Action’ drop down field, the BO User1, via the ‘Details’ tab, will update the action to
be applied to FO_AMEND
4. BO User1 will save trade by applying F5

Back in the Task Station, BO User1 will still see trade in his/her VERFIED_TRADE tab (as status
does not change in the manual authorization logic until change has been accepted).
BO User1 can apply ‘Process’ if he/she would like to mark that they are the current ‘owner’
of the task while waiting for approval/rejection, but as there is aCheckPendingModification rule on
the action FO_AMEND, other users cannot apply action in between.
Should the user or another try to apply an action on that trade task, the system will throw an
exception.
BO User1 would need BO User2 to accept or reject the changes/amendments made.
Accessing different components from the Trade related task.

In addition to performing tasks on the trade task (using the Task Station), BO User1 can also:
1. Highlight a task and via ‘Trade’ Menu, open and verify (or amend) underlying trade directly from the
Task Station
273
Notes:
2. Highlight a task and using ‘Product’ Menu, open and verify (or amend) Underlying Product
3&4
3. Highlight the task and using ‘Counterparty’ open and verify (or amend) Legal Entity Window for
Counterparty details
4. Highlight the task and using ‘Contact’ Menu, open and verify (or amend) Contact details of the
Counterparty
5. Highlight the task and open the ‘Simulate’ Window to simulate an action on a task without actually
applying it
6. Highlight the task and in the bottom portion of the Task Station’s particular tab, review the Task
Summary window
The BO User can check the
6 Trade date & Settle date of
trade, Principle (notional or
actual) to be exchanged, the
price actual settlement of
trade with the currency, the
counterparty in question and
the transacting trader.
274
Notes:
Example of BO User1 executing Transfer related tasks using the Task Station:
While BO User1 waits for validation of change on both ‘Different User’ and ‘Manual Authorization’
scenario above, he/she would be using the Task Station to handle tasks generated as a result of
system events and/or an event that has occurred on the other components
(transfer/messages/postings/exceptions).
For example, as a result of the Equity trades saved above, in the VERIFIED_SECURITY tab, the BO
User1 will have transfer related tasks (where in our case, due to our configuration, the underlying
transfer is in VERIFIED status).
The actions applied on the transfer tasks will be dependent on the organization’s needs, the Transfer
Workflow and access permissions setup. These will determine if and when BO User1 can perform
actions on and/or monitor/load transfers.
Having checked and verified that all the details of the transaction are correct for the payment of cash
and the receipt of security (Equity example) in question, the BO User1, according to workflow setup,
can move the transfer through its lifecycle by conducting next few steps on his/her task.
Of course the BO User1 would go ahead and process transfer only after having confirmed
that all financial details correspond with relevant updates/changes conducted on trade.
Should, as in our Manual Authorization case, amounts change, then the BO User1 needs to
confirm the changes on the trade have been accepted and if so, that the initial generation of
transfer amounts have been amended/updated to correspond with the new transaction (Workflow
permitting) amounts.
1. Highlight task in VERFIED_SECURITY Tab and ‘Process’
275
Notes:
2. From the choice of actions available to the BO User1, apply the action ‘SETTLE’
3. When the TSSettlePanel opens, the BO User1 can transact the payment order by clicking the
‘Apply’ button
Accessing different components from the Transfer related task

In addition to performing tasks on the transfer task (access rights permitting) using Task Station, the
BO User1 can also:
1. Highlight the transfer and right-click to open/verify and amend the ‘Trade’ directly from the Task
Station
2
&
3
2. Highlight the transfer and right-click to open the ‘BO Trade Browser’ directly from the Task
Station to check on the back office components of the trade
276
Notes:
3. Highlight the transfer and right-click on ‘Transfer’ to open the Transfer Viewer window allowing
user to view all details of the transaction
The Transfer Viewer informs of the

BO User of the amount that was
transacted, with whom it was
transacted, the trade that it is
associated with, the settlement
accounts that are going to be
affected by the movement the
direction of the transfer, the dates
associated with the exchange, how
the transaction will be exchanged
and what (in this case) security is in
question.
• Highlight the transfer and right-click to open/verify and amend the relevant Settlement Delivery
Instruction (Receiver Instruction will show the receiver of transfer SDI)
• Highlight the transfer and right-click to open/verify and amend the relevant Settlement Delivery
Instruction (Payer Instruction will show the receiver of transfer SDI)
• Highlight transfer and right-click to open/verify and amend the ‘Messages’ attached to the
transaction visible via the message report
277
Notes:
• Via the ‘Message TradeId linked’ Menu BO User1 can open/verify and amend other messages
linked to transfer not necessarily visible through the message report
• Via ‘Validate SDI’ BO User1 can confirm SDIs related to transfer should there be any SDIs
related to transfer that need confirming
• The ‘Flows’ Menu opens the ‘Flows Detail For Transfer report and allows BO User1 to verify the
cashflows/security flows associated with the transaction. This will show both the security and the
cash exchanged
• ‘Simulate’ allows BO User1 to simulate an action on the transfer without applying the action
All available actions

within the Transfer
workflow will be
displayed.
• Highlight a transfer and view the Transfer Summary window below
Double-clicking the blue labels will bring up the flow amounts or the SDI instructions related to
movement.
Section to the right
informs user what
Section to the left
the agreed security
informs user what
amount is and the
method both the PO
Principal cash
and the Cpty will use
amount in the
to move transactions
exchange. The
(payments) to the
delivery instructions
relevant agents
of accounts at
/custodians. This
agents/custodian
information is attached
to be affected by
to the transfer and
transaction are
comes from the SDI
listed. This is
setup.
derived from the
SDI attached to the
transfer.
278
Notes:
Example of
BO User1 executing Message related tasks using the Task Station:

The tasks related to the messages generated as a result of the Equity trades transacted will be visible
to the BO User1 his/her VERIFIED_MESSAGE Tab CONFIRM message in VERIFIED status -
generated from Trade object - and RECIEPTMSG message in VERIFIED status - generated from the
Transfer Object. These messages will follow their own lifecycle according to the Message Workflow
defined.
Workflow setup and access permission permitting, the BO User1, will perform their tasks on the
messages tasks (performing manual tasks, solving STP breaks, and applying amendments) using the
Task Station. The relevant actions and monitoring of messages will take place with the aim of moving
the messages along their lifecycle conveyer belt.
The BO User1 will apply tasks using the same procedures as the trade and transfer related tasks i.e.:
1. Highlight task in VERIFIED_MESSAGE tab
2. To ‘own’ task, click on ‘Process’
3. Using either the Actions menu or by right-clicking to obtain the action ‘Menu,’ the BO User1 would
apply an action (in this case ‘SEND’)
BO User1, would see the Sent messages in the SENT_MESSAGE Tab.
279
Notes:
Kick Off / Cut Off Scenario:

We have already discussed the ‘Kick Off/Cut Off’ functionality in Calypso where tasks were
automated and expedited by the Task Engine at user-defined times for user defined workflows.
Should there be a Kick Off/Cut Off configuration, the result would just be that the system, at the time
and intervals indicated would move messages along their lifecycle.
When 17:30 arrives, the Kick Off (based on the configuration) would be started by the Task
Engine, moving automatically all messages in VERIFIED status to SENT.
280
Notes:
The automation of task (setup timing of Kick off/ Cut off) would normally be coordinated with the both
sender and receiver organizational deadlines. The set-up of Kick Off time would have taken into
consideration that all checks from the sender of message have been done before ‘kick off’ launches
and that the receiver is able to receive it during the time stated.
Accessing different components from the Message related task.

In addition to performing message-related tasks using the Task Station, BO User1 can also:
• Highlight the task and via ‘Amend’ Menu and open the TSAmendMessage Panel to amend the
underlying message
281
Notes:
• Highlight message and right-click ‘Trade’ to open/amend/verify the trade related to the message
• Highlight message and right click to open the ‘BO Trade Browser’ window to verify the Back
Office components
• Highlight message and right-click to open the ‘Message Viewer’ window to verify details of the
Message and to allow viewing the message by clicking the ‘Latest Document’ window
The message type, depending on whether it’s trade or transfer related, will show in the
Transfer tab the associated transfer related to the message. The Tasks tab will show the task
related to the message.
The information
retrieved in this
window is a
combination of the
workflow followed
by the Message,
the Message
Configuration
setup, and trade
information.
282
Notes:
• If the message is derived from a transfer, then user can highlight message and right-click to open
the ‘Transfer Viewer’ window. This window has been covered in the transfer related menus
above
In the same way as users can obtain the message vie the ‘Message’ view (by clicking Last
Document button in the Message Viewer window) the Message generated can also be
directly viewed by highlighting the relevant task and clicking ‘Message.’
• Highlighting a message task and clicking on ‘Receiver’ will open the Legal Entity window,
allowing user to view/modify the receiver
• Highlighting a message task and clicking on ‘Contact’ will open the counterparties contact details,
allowing the user to view/modify details
• Highlighting a message and clicking ‘Payment Details’ will update the summary table at the
bottom of the Task Station. The information provided in the Summary table will be different
dependent on whether the source is a Trade Object or a Transfer Object
For a trade related

object, the summary
will show details
from the
Counterparty
Contact details and
the method used as
identified within the
Message
configuration. The
status of the message
will also be displayed.
For a transfer
related object, the
information
displayed is the
transfer payment
instructions.
• Highlighting a message and clicking ‘Task History’ will open the Task History window and show
the task history of the relevant message
283
Notes:
• Highlighting a message and clicking on ‘Flows’ will show the cash flows/securities flows if the
message’s source is a Transfer object
• Highlighting a message and clicking ‘Simulate’ will allow a user to simulate the actions on the
message workflow without applying them
BO User2 Handling Tasks

The BO User2, in addition to processing tasks with the same access rights as BO User1, can also
authorize tasks given the authorization possibilities by using the Workflow. With the
changes/amendments done by the BO User1, we will now view the actions BO User2 would transact
as part of his/her authorization functionalities.
We reiterate that, like the other users, the tasks transacted by this user also are dependent on
workflow and access permissions.



PENDING
AUTHORIZ
E
284
Notes:
Different User: BO User1 makes amendments to the trade:
Diff Users/E
Original Resultin Access
Action Task STP User/Manual Rules xecutor
Status g Status Perms
Auth s
PENDIN
VERIFIE BO_AME Bo
G_FO_A Yes Bo/ops
D ND user1
MEND
PENDIN
BO_AME VERIFIE CheckNoChan Bo user
G_FO_A Yes Bo/ops
ND D ge 2
MEND
PENDIN
VERIFIE Bo user
G_FO_A REJECT reject Bo/ops
D 2
MEND
Manual Authorization: Due to the ta/Front Office’s request that BO User1 update the trade:
Diff Users/E
Original Resultin Access
Action Task STP User/Manual Rules xecutor
Status g Status Perms
Auth s
PENDIN
EX_TRADE Accept Bo Bo
G_FO_A Yes
_AUTH /Reject user1 user2
MEND
Assume the ta/Front Office needs to update the trade:
Diff
Original Actio Resulting Users/Ex Access
Task STP User/Manua Rules
Status n Status ecutors Perms
l Auth
BO_A PENDING
Ta/Middle Ta/Middl
VERIFIED MEN _FO_AME Yes
Office e Office
D ND
BO_A
PENDING_F CheckNoCha
MEN VERIFIED Bo user1 Bo/ops
O_AMEND nge
D
PENDING_F REJE
O_AMEND CT
Like the other users, BO User2 would open the Task Station when selecting himself/herself as a user.
• From the ‘Configure’ Menu, the user would choose ‘Set User’ to select him/herself as user on the
Task Station
285
Notes:
Once selected as the user:

1. The From/To dates need to be adjusted accordingly
2. The ‘Load’ button needs to be clicked
3. The configuration of the Task Station tabs will be adjusted according to the User Config setup
configured for this user
1
2
3
The BO User2 will see the Task Station updated with tasks to either perform actions on or monitor.
1. BO User2 will see task in his/her VERIFEID_TRADE tab
2. The BO User2 can see a task has already been transacted on it is highlighted ‘blue’ and the task status
is updated to ‘UNDER_PROCESSING’
The ‘Task
Owner’ column
would let the BO
User2 know who
1 the task is
2 owned by.
286
Notes:
Example of BO User2 executing trade related tasks using the Task Station
For this scenario, BO User1 has made amendments to trades where he/she has permissions. The
following is an example of the four-eyes principle.
1. The TRADES_APPROVAL/REJECT tab shows the BO User2 that he/she has to authorize an action
performed by a colleague (in this case, the BO User1 had used the ‘Different User’ 4-eyes principle)
In this case, we can see that the trade status has changed to PENDING_FO_AMEND and the
BO User2 has an action to apply using the Task Station. To accept or reject the change in
this case, the process remains the same as any other application of an action via the Task
Station.
2. BO User2 would highlight the task and click the ‘Process’ button
In order to see the amendment done on this trade, the BO User2 would have to right-click the
task and pull up the trade via the ‘Trade’ menu.
3. Highlighting the task, BO User2 either accepts by applying the action BO_AMEND or rejects by
applying REJECT. The user chooses to REJECT
287
Notes:
This particular task for BO User2 is now moved to COMPLETED status.
Manual Authorization User Scenario

1. The BO User2’s TRADES_MAN/AUTH_APPROVE/REJECT tab will show that he/she has to
authorize an action performed by a colleague (the BO User1 had used the ‘Manual Authorization’
four-eye principle)
The BO User2
would be able to
As per the Manual see the Comment
Authorization on the task the BO
logic, the Status of User1 has input.
the underlying
i
Trade will still be
VERIFIED.
1. To accept or reject the change in this case, the process remains slightly the same, but with an
addition:
In this case, we can see that the trade status has NOT changed, but remains as VERIFIED
(this is also why the trade still appears in the VERIFIED_TRADE Tab). Although there has
been an amendment and an action transacted by BO User1, the system has not applied the
change.
288
Notes:
The change only takes place if the BO User2 accepts. If BO User2 does not accept, the trade
keeps its current status and change would not be affected. Task will in the meantime show as
‘Under Process.’ Assuming that task ‘comment’ added by BO User1 will not be enough and
BO User2 would like to review changes/amendments made on object, they can.
2. ‘Own’ the task by highlighting the task and applying ‘Process’
3. From the Task Station > Action Menu, choose ‘Show Object’ or by right-clicking on the task and
selecting Action Menu > Show Object
BO User2 would see the trade object in its previous state before the change.
4. From the Task Station > Action Menu, choose ‘Show Current’ or by right-clicking on the task and
selecting Action Menu > Show Current
BO User2 would see the trade object in its ‘temporary’ changed state. Recall that the change
has not yet been applied.
289
Notes:
In the Manual Authorization scenario, the BO User2 has a few choices to apply the actions
Accept or Reject. BO User2 can either:
1. Navigate to Task Station Menu > Action > Accept/Reject or by right-clicking on the task and selecting
Action Menu > Accept/Reject
2. Navigate to Task Station Menu > Action > Show Modifs or by right-clicking on the task and selecting
Action Menu > Show Modifs
290
Notes:
He/she can view the modifications that have been made using ‘Accept/Reject’ buttons
The Authorization window allows BO User2 to double check the changes

made. The Quantity/Old/New columns tell the user what part of the trade
has changed. If satisfied, user can accept using this window or if not,
reject.
Once BO User2 has accepted or rejected the task, it will be considered ‘COMPLETED’ for him/her
and be removed from the BO User2’s TRADES_MAN/AUTH_APPROVE/REJECT Tab.
291
Notes:
7.5 Authorization & Audit

By reviewing a few of the examples given above, we can see on a very small scale how throughout
the day, a lot of activity can transpire on a trade, transfer, and message. An organization, for security
purposes as well as for regulatory reporting purposes, needs to control and have visibility of all
activities that transpire within. To address this, Calypso provides a clear means to track, authorize
and audit the multitude of activities that can be conducted using the system.
We have already started building the access rights a trader would need to price his/her trades before
they decide to transact the trade. Inherently, we gave access rights to trader x to be able to price and
save his/her trades. We also gave access rights to calypso_bo eod marks user 1 to input the EOD
marks. These are the official EOD marks the trader will use vs. his/her live feed (Reuters for example)
to assess the market:bid/ask price vs. yesterday’s closing price.
Now let us use a Swap scenario to review quickly how users can audit & authorize (a subject we
covered already during the Manual Authorization Equity scenario) activities in Calypso.
Quick glimpse of Swap Trade Scenario

EOD Marks
Main Entry> Market Data > Market Quotes > Quotes

• calypso_bo eod marks user 1 inputs the EOD marks for 3 month LIBOR and clicks ‘Save’
The EOD Marks are usually input in volumes thus EOD Scheduled Tasks
(EOD_PLMARKING) would normally be used.
Once marks have been input, the system will display a message letting the user know that
quotes have been saved, and that authorization is required.
292
Notes:
Authorization
Main Entry> Processing > Data Authorization

• calypso_bo Management user 1 can highlight all the changes and accept/reject as desired
The
calypso_bo
Management
user 1 will be
able to load
the
authorizations
related to the
users listed
under ‘users’
and view
changes to
accept/reject.
Trade Input
Main Entry> Trade > Interest Rates > Swap
• A Swap trade is input by trader x

The Swap trade stops at PENDING as the STP rule ‘Cpty Not Chase’ has been broken and
PO cannot trade with this Counterparty
293
Notes:
Cancel Trade
1. Assuming that the ta/Middle Office user has access rights to ‘Cancel’ trades (action MO_CANCEL),
ta/Middle Office user cancels a trade as PO cannot transact trades with the Counterparty
294
Notes:
295
Notes:
Trade Audit
If users wanted to monitor the activities that transpired on a trade, Calypso provides a few of different
ways to monitor and audit them. The Back Office menu of any trade window allows users to view the
audit related to the particular trade in several different formats.
Trade Window > Back Office Trade Menu > Audit
In the ‘Versions’ format users can view the latest version of a trade, showing version numbers, time of
change and the users who made changes.
Informs users
on version
changes of trade
done by whom
and when.
In the ‘Field Details’ format, the view provides more detail into the changes by not only supplying the
above details, including information as to what was changed.
In the ‘Trade Audit’ format, the view adds additional detail by providing further detail to the changes.
296
Notes:
As part of Calypso’s report framework, the Trade Audit report is also available for all Trades in the
System via:
Main Entry > Reports > Trade Audit
Users can use the top criteria section to filter the Audit on any trade in the system.
Audit Report
Calypso provides a global audit reporting tool for all activities (including trade auditing) to view
changes done using the system, which is the Audit Report.
Main Entry> Reports > Audit > Audit Report
297
Notes:
Audit via Task Station

Via the Task Station, Back Office users can view the audit on a particular task by right-clicking on the
task. Right-clicking on a trade related task, users will have access to the Trade Audit (Latest) Menu.
The Trade Audit (Latest) Menu allows users to view the latest (last) update on the trade.
298
Notes:
By right-clicking on a trade related task, users will have access to the Trade Audit (Full) Menu. The
Trade Audit (Full) Menu allows users to view the full audit on the trade object.
299
Notes:
Payment Audit
By right-clicking on a payment related task, users will have access to the Payment Audit Menu.
These options will bring up

the trade audit window.
The Audit Report window will open to show in the Field Name column, what
was changed and the New Value shows the actual change made on the
payment.
Message Audit
By right-clicking on a Message related task, users will have access to the Message Audit Menu.
300
Notes:
The Audit Report window will open to show in the Field Name column, what
was changed and the New Value shows the actual change made on the
message.
301
Notes:
Module 8: Component
Reports, Position Monitoring
& EOD Scheduled Tasks

• Determine common Report Framework tools
• Identify Treasury positions held by Organization
• Manage Cash/Security positions
• Determine how Calypso monitors financial Instruments held and

the P&L associated
• Describe the use of End-of-Day (EOD) batch processing for

financial organizations
• Identify some of the basic Back Office related batch processes.

MODULE 8 Reports & EOD Scheduled Tasks
Introduction
It is essential that anyone working in a financial institution have access to up-to-date reports regarding
their positions. In terms of reporting, we will be discussing how Calypso, using Calypso Framework
reporting capabilities, records the already discussed (Transfer, Message, Posting) Back Office
components and we will also introduce Treasury Management and Product (instrument)
Management.
During our discussions related to Treasury Management and Product (instrument) Management, we
will discuss the subject of ‘Engines,’ focusing on the two remaining engines, the Inventory Engine and
the Liquidation Engine.
At the end of this module, we will briefly give an overview of the End-of-Day (EOD) batch processing
tool Calypso provides, and outline which of those processes could be run by EOD end users.
303
Notes:
8.1 Common Features of Reports

The outcome of the daily operations of a bank and the processing of a trade results in the generation
of several forms of data. Part of the management of processes requires that the data produced are
captured in a timely manner, reported accurately and are dispatched amongst interested parties.
Calypso’s report framework provides users a full range of reports to allow them to produce the desired
results, using different means of configuration and data supply dependent on whom the receivers of
the reports are. The framework is a rich functionality that gives users the means to convey relevant
information to the relevant parties in a multiple verity of ways. Apart from the authorization report, the
audit report falls under the Calypso Report Framework functionality.
In this Module we will be covering the basic reporting tools available and showing them with the
results of our business cases covered.
Features Common to all Calypso Reports

The Calypso out-of-the-box reports provided as part of the Report Framework tool is highly
configurable, allowing users to filter information according to their specific business requirements.
Although, the reports pertaining to this beginner’s course (Trade Browser, Transfer Report, Message
Report, Accounting Report, Inventory Report and Position Keeper) will be described below in their
respective sections; as they are all within the Report Framework tool, these different reports share
some common features. We will review some of those features quickly here.
The shared features include the following:
• Report results can be displayed for a given set of criteria
• For most reports, the Criteria panel is located (by default) in the top portion of the Report Window
• The available criteria’s for each report ranges and is dependent on the type of report. Using the
criteria section, users can specify search criteria as applicable and click to load the corresponding
transfers
You can use toggle (as per screenshot below) or check/uncheck View > Show Frame > Criteria to
display or hide the search criteria.
The toggle icons allow users

to show or hide the Criteria
section.
304
Notes:
OR
In general, the results for all reports are loaded in the bottom section of the window.
To load the results, almost all reports have a ‘Load’ icon on the top left corner of the Report window.
A loading menu is provided via the relevant Report menu (view screenshot below):
OR
In order to allow users to display/load a given set of criteria’s on a regular basis, reports (via Report
Menu > Save Template) allow users to configure and save user defined Templates. Consequently users
load or delete these templates.
Further information on Templates is provided in the ‘Template Configuration’ section below.
305
Notes:
Unless otherwise specified, report results are displayed from the perspective of the Processing
Organization.
Using the ‘Data’ menu, report results can be ordered dynamically by any column and users can
specify subheadings, totals and custom column names.
Using the ‘View’ menu, users can view the report results in a simple table, pivot table, or an
aggregated table format.
306
Notes:
Out-of-the-Box report results can be exported to HTML, Excel, CSV and PDF. If users have the
necessary Visokio.jar installed in their classpath, management/statistical reports can also be
accessed by selecting ‘OK’.
The pricing detail used by each report is listed at the bottom of the window.
By default, the Pricing Environment used by each report comes from the User Defaults, and the
valuation date (which can be seen when the drop down arrow is selected) is the current date and
time.
If required, you can change the pricing details by clicking on the symbol and inputting the desired
valuation date and time.
In general, relevant reports are accessed by navigating to:
Main Entry > Reports >
307
Notes:
• Message Report
• Transfer Report
• Accounting Report
• Inventory Report
Main Entry > Deal Management >
• Trade Browser
Main Entry > Processing >
• Task Station
• Data Authorization
• Generic Comment Editor
All of these reports offer the general features of the report framework described in any report
window via Help > Menu Items.
For help on the specific report, each report allows users to select the relevant help via Help >
"report type". For example: Help > Message Report.
Template Configuration
Calypso provides an out-of-the-box default HTML report template (registered under the domain value
REPORT.Template) that allows users to define their own relevant report templates containing free-
form text as well as template keywords. If the same information be required on a regular basis from
certain reports, having predefined templates will allow this functionality to give users the ability to
retrieve useful information customized to the readers/receivers needs.
308
Notes:
The use of templates can prevent users from re-imputing reoccurring criteria fields and re-loading on
a regular basis the same data. For this module, we have customized a few of our reports in order to
give you an example of how the data output (from the relevant components addressed across our
modules) can be presented and how it can be used to provide users/readers relevant comprehensive
information.
You can customize your own templates, using the same steps provided below.
Create a Basic Template

From any report, using the top criteria sections determine/define the relevant search filters you/your
business requires.
After you have defined your criteria, using the ‘Report’ menu, select ‘Save as Template’ in the
Report dropdown menu.
The ‘Report Template’ Window will open. Using the blank field, enter the name for your template and
select ‘OK’.
309
Notes:
The system will prompt you to save the template as private or public. A private template cannot be
accessed by other users.
Private report templates can be used only by the user who creates them, and public report
templates can be used by any user, provided the proper permissions are granted.
Provided the proper access permissions, when you next want to load the template saved, you can do
so by going to the relevant report and from the report menu select ‘Load Template’
Choose from the List of

templates saved. You
can also search using the
‘Search text’ field.
Once found, select ‘OK.’
Once you have selected the Template, you can show results in the bottom section by reloading (using
icon or report menu > load)
or
310
Notes:
8.2 Specific Component Reports

In this section, we will go over some of the reports that are related to the specific components of the
trade and give you an overview of their output and how they can be used.
Trade Browser
In general, traders will not be reviewing, searching or overseeing their trades or activities in the same
way as the Back Office users. The Trade Browser (as well as the Trade Blotter depending on
preference) is one of the means a Trader/Trading Assistant can manage and monitor the trades
transacted by themselves, their trading book, processing organization, etc. Back-Office operational
users will use specific component reports and task station as their tool for reviewing and monitoring
trades transacted.
To access the Trade Browser report, navigate to:
Main Entry > Deal Management > Trade Browser
To view Trades transacted by CUB Processing Organization, navigate to Report Menu > Load
Template, load the predefined template ‘Back Office Course_CUB TRADING.’ Once having selected
template, (using icons or menu) re-load the report
Result:
When the template is loaded, the Trade

Browser has filtered the relevant Equity &
OTC Trades transacted by PO CUB showing
preliminary details concerning the
transactions.
311
Notes:
Transfer Report
In addition to accessing transfers related to a trade via the related trade window, you can also view
the transfers generated by the transfer engine via its own dedicated Transfer report. From here, you
can apply a number of actions to the transfer based on the transfer workflow configuration. Actions
can also be applied from the task station and the Back Office window.
To apply an action from the transfer report, right-click a transfer and choose the action. The actions
defined in the standard workflow are described below.
312
Notes:
Show Simple View

It is important to note the difference between transfers and payments:
Transfers - A transfer is any movement of cash or security attached to a Trade that is expected to
occur.
Payments - A payment is a transfer of cash or security that has actually occurred.
Main Entry > Reports > Fees & Settlements > Transfer Report
To view messages in Simple Table view, navigate to Report Menu > Load Template, load the
predefined template ‘BOPosition – Payment Sorting – Simple View.’ Once having selected template,
(using icons or menu) re-load report.
Show Pivot View

predefined template ‘BOPosition – Pivot.’ Once having selected template, (using icons or menu) re-
load report.
313
Notes:
Message Report
You can view the messages generated by the Message Engine using the Message report. The status
of newly created messages depends on the workflow configuration (if the contact information is
specified, the messages will be in status VERIFIED).
Simple Table View
Main Entry > Reports > Message Reports > Message Report
predefined template ‘Back Office Message Sorting – Simple View.’ Once having selected template,
(using icons or menu) re-load report
314
Notes:
Pivot Without Status

To view messages using the Pivot view, navigate to Report Menu > Load Template, load the
predefined template ‘Pivot Event_Type & Message_Type.’ Once having selected template, (using
icons or menu) re-load report.
315
Notes:
• Double-clicking cell with value will open the up the underlying Message
• Right-clicking cell with value and selecting ‘Show Details’ also has the same result
316
Notes:
• Right-clicking on a cell with a value will give users options to perform actions on the message
Pivot with Status

To the above pivot Message report, adding status to the report will give further meaning to the report
reader.
To see the results of this, navigate to Report Menu > Load Template, load the predefined template
‘Pivot Event_Type & Message_Type w/status.’ Once having selected template, (using icons or menu)
re-load report.
317
Notes:
Aggregation view
To view messages in aggregated view, navigate to Report Menu > Load Template, load the predefined
template ‘Back Office Message Sorting – Aggregation View.’ Once having selected template, (using
icons or menu) re-load report.
318
Notes:
8.3 Treasury: Cash and Security Management

The job of the Inventory Engine is to track/maintain/update the amount of given cash and/or security
an organization owns at agents, custodians, and depositories. These can be Cash and Security
positions that a Procession Organization owns or positions of the Processing Organizations’ clients,
who have their holdings at the PO i.e., as safe Custody.
As we went through this course, we showed you how from the transaction of a Trade different
components were derived. We broke down the configuration process to show you how the transfers
were able to get generated and then, once generated we showed you (using Workflow) how they
moved along their lifecycle affecting messages and / or postings (where required).
By reviewing the ‘Task Station,’ we showed you how a Back Office Operations administrator was able
to use a platform from which he/she could oversee, manage, monitor and adjust (where necessary)
the generated transfers. The goal being to assure the transfers followed their lifecycle course as
seamlessly as possible until (using their workflow) they were ‘SETTLED.’
Why all this? For the simple reason that transfers (cash/security) are actually the basis of financial
institutions revenue, thus need to be properly executed, administered along their lifecycle and
managed. The Inventory Engine tracks/maintains and updates the amount of cash/security of an
organization because this is the way in which Calypso provides the means to determine the
Organizations revenue.
In most financial organizations, the management of cash/security is done by treasurers. In this
section, we will cover how a ‘treasurer’ can manage/monitor the bank’s revenue using Calypso.
Proper management of revenue determines the financial health of the company and saves the
company from unwanted surprises. As a result, the main objective of a ‘treasure’ is ensuring that the
cash /securities held by the organization are sufficiently transparent. Sufficient transparency would
give the treasurer the visibility over the accounts going into debt. He/she can avoid accounts that
would be charged interest due to debt incurred or in some cases being over credited on certain
accounts at certain agents and if needed, he/she can put up necessary flags to traders. For example,
Euro account at a particular agent is short and thus he transaction needs to be made to maintain
sufficient balances on the account.
Calypso’s Inventory Position functionality gives organizations a near-term liquidity management
functionality facilitating a treasurer’s job by giving him/her the means to reconcile with positions at
agents, manage expected flows, the settled flows, non-settled flows and the flows to come.
Inventory Engine & Subscription of Events

To review configuration in place for the Inventory Engine, navigate to:
319
Notes:
Select the event class PSEventTransfer and

assign the Inventory Engine as a subscriber by
using the Consumer field.

320
Notes:
The Inventory Engine publishes the following events:

• PSEventInventoryCashPosition
• PSEventInventorySecurityPosition
None of the Engines depend on these events published by the Inventory Engine.
However, the Back Office uses these events.
• Corporate Action process depends on Inventory positions.
• The Scheduled task ACCOUNT_STATEMENT depends on inventory positions.
• The Scheduled task ACCOUNT_INTEREST depends on inventory positions to generate
Account interest trades.
• The Scheduled task EOD_BROKER_STATEMENT depends on inventory positions to calculate
the correct positions before generating Clearer (Cash Adjustment) trades.
• The Scheduled task ACCOUNT_BILLING depends on inventory positiions to generate Account
billing events which effect the generation of billing trades.
When started, the Inventory Engine loads all outstanding events for processing. In order to optimize
the processing, it sorts them by settle date. It also loads the outstanding positions for cash and
securities.
Once you have defined the subscription of events for the Inventory Engine, you will need to make
sure that the Transfer and Inventory Engines are running to compute inventory positions.
You can access Back-Office Inventory Position by navigating to:
Main Entry > Reports > NOSTRO / Custodian Positions > Inventory Position
The fields available in this

Criteria section varies slightly
dependent on the type of
Inventory (Cash and/or
Security Inventory) selected.
The results shown in the bottom portion of this

report are dependent on the selected Criteria’s
chosen in the top portion of this report.
321
Notes:
Business Logic
As we mentioned, Back Office positions are computed based on transfers of cash and securities that
hit ‘SETTLE’ accounts.
For this this course, it is sufficient to mention only the basic features (Dates, Position – Cash and/or
Security, Position Date, Position Class, Position Type and Aggregation level) so that you have
enough of the building blocks to understand the basics and the courses to follow.
Dates
Like all reports in Calypso, the Start and End dates need to be defined for your search criteria to be
confined within a specific periods.
• Start: Positions will load in table from the stated start date input in this field
• End: Positions will load in table from the stated End date input in this field
Inventory Selection
In the Cash/Sec drop down field (screenshot below), users are allowed to select the Cash and/or
Security (or both) position they would like to view within the Inventory Report.
Defining Position Dates

The Inventory Engine calculates positions by Trade Date and by Settle Date (or available date if
positions are client positions). It does this to allow the Processing Organization to monitor in real-time.
Its cash/security positions with its agents (NOSTRO/custodian, etc.) and the cash/security positions of
its clients.
The following positions are available:
322
Notes:
• By Trade Date; Positions are computed based on the Trade Date of the Trade related to the
Transfer
• By Settle Date: Positions are computed based on the Real Settlement Date of the Transfer
• By Available Date: This only applies to Client positions, i.e., if Position Class = Client. Positions
are computed based on the Available Date of the Transfer. The domain value xferAvailabledate
can be used to determine the sense of ‘Available date’ for specific flows
This is mainly for customer activity and the Calypso’s Clearing solution makes use of this
functionality to determine Client statements. For further information, please refer to the Calypso
Documentation specific on the Clearing Solution.
• By Value Date: Positions are computed based on the Value Date of the Transfer and are only
applicable to the position type ‘Actual’
• By Booking Date: Positions are computed based on the Booking Date of the related Transfer
For this course, we will be working with the Position Date ‘Settle.’
Defining Which Positions

Calypso allows users to define which positions they would like to see in the Inventory report.
The following Positions are available:
323
Notes:
• External: Class used to represent positions imported from external sources for reconciliation
purposes. The positions can be imported manually (custom) or by a swift MT535 (sent by the
Agent)
• Internal: Processing Organizations positions on Settlement accounts
• Client: This is only for Client positions. These are positions held by Processing Organization for
its clients
• Margin Call: Represents Margin Call positions
During this course, we will be setting the Position Class to ‘Internal.’
Aggregation
Calypso provides a range of aggregation levels in which positions can be viewed. The screenshot
below shows you the list of the available ‘Position Aggregation’ levels users can select from.
324
Notes:
Once selected the bottom portion of the Inventory Position will reflect the level of aggregation
selected:
• Agent: Positions held at a particular agent will be shown aggregated at the Agent level
• Agent/Account: Positions held at a particular agent will be shown aggregated at the Agent and
Specific Account level
• Book: Positions held on a particular Trading book will be filtered and shown
• Book/Agent: Positions held on a particular Trading Book at a particular Agent will be filtered and
shown
• Book/Agent/Account: Positions held on a particular Trading Book at a particular Agent on a

specific Account will be filtered and shown
• Client: Positions held for clients will be shown. It displays the position aggregated by Client (for
all the accounts of each client)
Note that for an INTERNAL position, ‘Client’ means Agent.

• Global: Global is a position by Currency or Product. For all PO/Agent/account.
• ProcessingOrg: Positions held by a particular Processing Organization will be filtered and shown
During this course, we will be setting the Aggregation level at ‘Book/Agent/Account.’
Position Type
Calypso has a range of ‘Position’ types. These Position Types determine the cash/security status.
This field is intricately linked to the transfer and the workflow status in which the transfer is.
325
Notes:
Using the field ‘Position Type’ when the user clicks the ellipses button, a window opens allowing
the user to select ‘Position Type’ from a range of position types listed to the left of the pop up.
The Position Types are in fact more like ‘Categories.’ Dependent on the Transfers workflow status,
the ‘Position’ (transfer of cash/security) is assigned (by the system or user) into specific categories.
Calypso is built with a large range of out-of-the box Position Types (categories). As the full range will
be explained in our intermediate course, we only need to mention the three main (standard) position
types.
• Theoretical: shows positions of any transfers based on the expected settlement date and
expected settlement amount, i.e. transfers in any status
• Actual: shows positions considered as ‘settled.’ These are transfers based on the real settlement
date and real settlement amount), i.e. transfers in SETTLED status
• Not settled: shows positions of all transfers regarded as ‘unsettled/failed’
For further information on ‘Not Settled’ category, Calypso uses domain values. Review to the section
on ‘processing Transfers’ below.
It is via this field that the treasurer can determine the revenue transparency of the organization. With
the Position Types concepts in place, he/she can determine the non-settled flows versus the settled
flows.
As mentioned earlier, should he/she require viewing other transparency levels (like the example given
earlier: expected flows or the flows to come), then he/she would need to configure the Position Types
‘Expected’ or ‘Forecast’ accordingly.
Processing of Settled vs. Failed Transfers

The three main Product Types were reviewed above. Now let us go through and clarify the general
terms Calypso applies to process transfers and positions.
Theoretical shows everything. This means all transfers in any Transfer status. This means that
transfers in the Theoretical position can be any of the below:
• New transfers (in any particular status i.e., PENDING / VERIFEID)
• Settled transfers (i.e., SETTLED)
• Canceled transfers (i.e., in CANCELD status)
Actual shows transfers that are both Settled and not Settled (example: VERIFIED). Thus, what an
organization considers as ‘SETTLED’ (according to the organization’s needs) has to be defined.
Not Settled shows all positions considers as ‘Failed.’ This could be transfers that are actually in
‘FAILED’ status or transfers that the organization considers as ‘failed’ transfers.
326
Notes:
What constitutes a ‘Failed’ transfer determines on what also constitutes transfers in the Position Type
Actual, thus ‘Settled’ transfers. The way in which Calypso allows an organization to determine their
own ‘failed’ and ‘Actual’ positions is by using domain values. Calypso has two domain values to
determine which positions are considered as ‘failed and/or settled.’
Below is an example of how the logic works:
• transferFailedStatus: This Domain Value determines which positions (transfers in which status)
the organization deems as ‘failed.’ All statuses indicated within this domain value will be
considered as part of the ‘Not Settled’ status
To add transferFailedStatus domain value, navigate to:
Main Entry > Configuration > System > Domain Values
1 2
3
5 4
1. Add your Domain Value using the ‘Search’ field and ‘domainname’
2. In the field ‘Name,’ make sure the field displays ‘domainname’
3. In the field ‘Value’ add transferFailedStatus
4. Click the ‘Save Above’ button
5. To add your domain value, click the ‘Add’ button
Conduct the below actions to add statuses considered as ‘Failed’ (to be included in the Not Settled
position):
327
Notes:
1
2
1. Using the ‘Search’ field, type transferFailedStatus and click the ‘Find’button
2. In field ‘Name,’ make sure the field displays ‘transferFailedStatus’
3. In the field ‘Value’ add transferFailedStatus
5. To add your domain value, click the ‘Add’ button
Conduct the below actions to add statuses considered as ‘Failed’ (to be included in the Not Settled
position):
1
2
5
4
1. Using the ‘Search’ field, type transferFailedStatus and click the ‘Find’ button
2. In field ‘Name,’ make sure the field displays ‘transferFailedStatus’
3. In the field ‘Value,’ add the Transfer Statue’s considered as failed (Example: PENDING)
328
Notes:
5. To add your domain value, click on ‘Add’ button
Repeat steps 3 through 5 to add ‘VERIFIED.’

6. Click ‘Save ALL Domains’ to apply your configuration
With the above logic in place, the Position categorization Calypso will apply would be the below:
• 'Theoretical' position = everything in the Inventory
• 'Actual' = SETTLED
• ‘Not Settled’ (failed) = PENDING and VERIFIED
Domain Value transferSettledStatus: This domain value determines which positions (transfers in
which status) the organization deems as ‘Settled.’
All statuses indicated within this domain value will be considered as part of the ‘Actual’ Position Type.
To add the transferSettledStatus domain value, repeat the same steps that were discussed in section
the above. The screenshot below shows the domain value being added.
To add statuses considered as ‘Actual’ (to be included in Actual position):
329
Notes:
1
3 2
5
4
1. Using the ‘Search’ field, type transferSettledStatus and click the ‘Find’ button
2. In field ‘Name,’ make sure the field is filled in with ‘transferSettledStatus’
3. In the field ‘Value,’ add the Transfer Statue’s considered as ‘Settled’ (Example: VERIFIED)
5. To add your Domain Value, click on ‘Add’ button
Repeat steps 3 through 5 to add ‘SETTLED.’
6. Click on ‘Save ALL Domains’ to apply your configuration
With the above logic in place (where the domain value transferSettledStatus = VERIFIED and
SETTLED) the Position categorization Calypso will apply would be the below:
• 'Theoretical' position: everything in Inventory (let us assume the inventory has transfers in
PENDING/VERIFEID/SETTLED status)
• 'Actual’ position: VERIFIED and SETTLED (no longer only ‘SETTLED’ as is set out-of-the-box)
• ‘Not Settled’ (failed): PENDING i.e. all status codes not stated within the domain value
transferSettledStatus will be considered not settled
If you set transferSettledStatus, then there is no need for transferFailedStatus.
330
Notes:
Whichever one of these domain values is configured to extend the organizations ability to dictate what
has failed and settled, most intraday Back Office treasurers would be interested in closely paying
attention to the Positions Types of ‘Actual’ and 'Not Settled.'
These two positions would be the positions that would show them a clearer view on the difference
between what has settled and what has not settled/failed.
Treasury Management
Revisiting the Equity and Swap trades, we can now show you how the transaction of those trades can
have a direct impact on the organizations treasury position.
Updating Positions
Before showing you an example of how the transaction of these trades would affect an Inventory
position, let us quickly go through the logic implemented by the Inventory Engine to update positions.
For the ‘Position Date’ specified (i.e. SETTLE DATE/TRADE DATE), the Inventory Engine, retrieves
the transfer positions of the transfers that settle into SETTLE Accounts.
Thereafter, it looks to see if there is ‘position’ that exists.
• If no position existed before, a new position is created
• If position exists for the transfer, the positions are updated and all future positions which may
depend on the updated position are updated
• If the Transfer is in CANCELED status, amounts are removed from the positions. Otherwise, the
amounts are added to the positions
Cash Position
In order to show you a clear way on how a Back Office treasurer can determine the revenue of the
organization, we have configured transferSettledStatus with SETTLED value only.
331
Notes:
When our Equity and Swap trades were saved, we had reviewed that they generated transfers. As we
have mentioned on many occasions, the transfers generated for these trades are generated to
represent the cash/security exchange to be made between Processing Organization CUB and the
Counterparty involved in the transaction.
Below is an example of how a trade is input and the transfers are generated and how Processing
Organization CUB’s Cash Inventory position is affected then updated accordingly.
For an Equity Transaction:
• Processing Organization CUB buys 50 shares of Peugeot (security) from BK XYZ and pays a
Settlement Amount of 185 Euros
th th
• The trade date is 19 March and the settle date is 19 March (2012)
As subscriber of PSEventTrade, the Transfer Engine consumes the event.

• Transfer Engine retrieves the necessary Cash/Security flows associated with the trade
• The Transfer Engine, applying TransferRules (SDIs against cash/security flows) generates
transfers
332
Notes:
DAP transfers have been generated and the flows have been
linked to the SDI’s corresponding to the PO and the Cpty
using Transfer Rules.
In conjunction with the Transfer Workflow, the Transfer Engine created a Transfer and the transfer
began progress down its own lifecycle.
• When the transfer reached VERIFIED status, the Inventory position is updated
Using all the information that is imbedded in the underlying transfer (Processing Organization, SDI
SETTLE Accounts, etc.), Calypso creates a clean breakdown of the Inventory position. To view
333
Notes:
position, navigate to the Inventory Position Report Menu > Load Template, load the predefined
template ‘Back Office Course – Equity Cash Inventory – CUB Trading.’
• Once the selected template has been saved, using icons or menu to reload the report
The Transfer Trade Date and Settle Date is 19 March

2012, and cash positions are updated from this day
on.
Highlighting the specific flow from top and

double-clicking shows the underlying transfer.
• Processing Org: The Processing Organization (CUB) is recovered from the underlying transfer
that was saved
• Book: The system retrieves the trading book from which the position is triggered by using the
underlying transfer from the trade cashflows. They will maintain the trading book information
• Position Type: As the domain value transferSettleStatus is set to SETTLED, and as long as the
transfer is in VERIFIED status, the position of the theoretical and Not Settled will be the same as
it considers everything but SETTLED as failed
When the transfer moves to SETTLED status, the Inventory position will update the position type
‘Actual.’ Once the underlying transfer has been ‘SETTLED’ the Actual Inventory Position will be
updated accordingly.
334
Notes:
According to the domain value

transferSettledStatus, the transfer
moving to ‘SETTLED’ status
updates the Actual Inventory
position and Not Settled position.
• Agent: Using the underlying transfer, the system has retrieved the Agent (Chase NY)
This is the Agent where Processing Organization CUB maintains their NOSTRO Account. For further
clarification, refer to account section below.
• Currency: Using the underlying transfer, the system retrieves the settlement currency
(determined at transaction of trade) in which the cash will settle
• Account: Using the underlying transfer, the system has retrieved the SETTLE Account that the
inventory position will affect
335
Notes:
This SETTLE account is attached to the underlying transfer via the SDI’s attached to the transfer. On
the SDI attached to the transfer, the SETTLE account mentioned is CUB NOSTRO Account.
When setting up the CUB NOSTRO Account for Processing Organization CUB, the account had been
setup as an ‘Auto’ account with attributes (view screenshot below) - - Xfer Ccy.
The result being, in fact, when the transfer was generated by the Transfer Engine, the system
(according to the attributes of the CUB NOSTRO Account setup) had generated an auto account
using the currency of the transfer. The transfer (via CUB NOSTRO Account) is only really affecting a
SETTLE account named - - EUR.
Accordingly, the Inventory Position in ‘Account’ section shows real SETTLE account affected by the
transaction.
• Account Type: The treasury management of Calypso is based on SETTLE accounts.
A SETTLE account is associated with the agent (in our case Chase NY) that settles the transactions
for Processing Organization CUB.
For a Swap trade:

• Processing Organization CUB Buys / Pay 5mill 10yr Swap paying semi-annual act/30 vs.
Selling/Receive 3m Libor quarterly act/360, Price: 5% against Counterparty BK XYZ
• The trade Start Date is 21 March and the Settle Date 21 is March 2022
• Currency = USD
336
Notes:
As subscriber of PSEventTrade, the Transfer Engine consumes the event.

• The Transfer Engine retrieves the necessary Cash/Security flows associated with the trade
• The Transfer Engine, applying TransferRules (SDIs against cash/security flows) generates the
transfers
337
Notes:
DFP transfers have been generated and the flows have been
linked to the SDI’s corresponding to the PO and the Cpty
using Transfer Rules.
As in the Equity case, in conjunction with the Transfer Workflow, the Transfer Engine created a
transfer and the transfer began its progress down its own lifecycle.
338
Notes:
On 21 June 2012 the Counterparty BK XYZ will pay (PO

receives) for the floating leg.
• Like in the Equity example above, when the transfers reach VERIFIED status, using all the
information that is imbedded in the underlying transfers and updates the Inventory position
• When the transfers are created, as in this Swap trade, all transfers related to the cashflows of the
Swap for the duration of the Swap’s life are created
• Each flow payment/receipt dates (Settlement Date) will be in accordance to the payment period
related to relevant leg
To view the position, using Report menu > Load Template, load the predefined template ‘Back Office
Course – OTC Cash Inventory – CUB Trading.’
Once having selected the template, using icons or menu to reload the report.
339
Notes:
On 21 June 2012, the Inventory position of PO

CUB is updated as positive representing the BK
XYZ payment.
• Book: The system retrieves the trading book from which the position is triggered by using the
underlying transfer, and the trade cashflows maintain the trading book information. In this case
‘OTC Trading Book’
• Currency: Using the underlying transfer, the system retrieves the settlement currency
(determined at transaction of trade) in which the cash will settle
• Account: Using the underlying transfer, the system has retrieved the SETTLE account that the
Inventory position has affected
Remembering the SETTLE account attached to the underlying transfer via the SDI’s was CUB
NOSTRO Account and that this account was setup with as an ‘Auto’ account with attributes - - Xfer
Ccy.
The result for the Swap position is that the transfers were generated by the Transfer Engine, the
system (according to the attributes of the CUB NOSTRO Account setup) generated an auto account
using the currency of the transfers.
The transfer (via CUB NOSTRO Account) is thus really affecting a SETTLE account named - - USD.
Accordingly, the Inventory position in ‘Account’ section shows real SETTLE account affected by
transaction.
340
Notes:
When each flow SETTLES, our Inventory position is updated

accordingly. In the example below, it shows the ‘Actual’
position being updated to show the ‘real’ (what has SETTLED)
Inventory position of the Organization and the NOT
SETTLED to show no breaks for this account at Agent.
The Calypso Cash Position Report can also be used to view cash positions by book and
to reconcile with the Inventory positions.
See this in Main Entry > Reports > Nostro / Custodian Positions > Cash Position
Security Position
Contrary to the Swap trade transacted (which only had cashflows), the Equity trade transacted
involves both Cash and Security DAP (Delivery Against Payment) transfers. As a result, when the
Equity trade was transacted and transfers were generated, the Inventory Engine updated both the
Cash and Security positions that were relevant.
To view position, select ‘Security’ as inventory type. Then, select Report > Load Template, load the
predefined template ‘Back Office Course – Security Inventory – CUB Trading.’
Once having the selected template, using icons or menu reload the report.
The report below shows an example of this:
341
Notes:
Highlighting on a
Security flow and
double-clicking allows
users to view
underlying/associated
flows that contribute to
the position.
In addition to the columns that were described during the Cash position example, for the Security
position and using the Security transfer of the Equity trade as an example, Calypso can retrieve:
• Product Id: Retrieves this from the Equity Security Transfer
• Product_CODE.ISIN:
Although it is not the Inventory Engine retrieving this

information, by using the Security flow, Calypso is able to
retrieve the product detail associated with the transaction.
• Product Description:
342
Notes:
8.4 Management of Instruments Held

We had reviewed that by default, when a trade was transacted, Calypso applied a form of separation
of design between trades and products in the way it treated trades vs. financial instruments traded.
As a quick recap, we had stated that a Product/Financial Instrument in Calypso was either:
• Referred to by Calypso users as ‘Position Based’ products (instruments such as
bonds/futures/stocks – product defined once but could be traded many times)
OR
• Non-position based = IR Swap or Cap/Structured Products, etc.
Nearly all Position Based Instruments are Secondary Market Instruments with the exception of
CommodityForwards, FX Forward’s and FX Swaps (which have their position built on the underlying FX
which is secondary market), etc.
In this section, we will refer back to this point for a couple of reasons. When a trade is transacted, if
the financial instrument in Calypso is ‘Position based,’ then Calypso manages that position in a
particular fashion.
Below are points on how Calypso handles this:
• Uses the Liquidation Engine to create positions
• Applies specific Liquidation rules on specific books and/or products
• Begins to create and maintain a ‘Trade Open Quantity’ position on the transaction
• Generates the Economic position for the relevant Product/Instrument
Liquidation Engine & Subscription of Events

To show how the management of financial instruments is conducted in Calypso, you will need to
launch and configure the Liquidation Engine. The Liquidation Engine is responsible for tracking and
updating position of instruments held by each trading book and reacts to Trade events.
To define a Liquidation Engine subscription, navigate to:
343
Notes:
From the ‘Consumers’ tab, select

the event class PSEventTrade and
assign the Liquidation Engine as a
subscriber by using the
Consumer field.
Use the ‘Add’ button to ensure

your selection is taken into
account before saving your
configuration using the ‘Save’
button.
Using the ‘Engine’ field in the ‘Filters’ tab,

select the Liquidation Engine and using the
drop down next to ‘Filter,’ select
‘PositionBasedEventFilter.’
This checks if the product of the trade is

‘Position Based;’ otherwise the event is
not processed.
Use the ‘Add’ button to ensure your

selection is taken into account before
saving your configuration using the ‘Save’
button.
344
Notes:
The Liquidation Engine publishes the following events:

• PSEventLiquidatedPosition
• PSEventUnliquidatedPosition
The Accounting Engine / Cre Engine depends on these events to produce accounting entries related to
positions (Mark-to-Market and Realized P&L) and Transfer Engine uses these events to produce
REALIZED transfers for Futures.
Liquidation Configuration
Once the subscription of events for the Liquidation engine has been defined, before the Liquidation
engine can calculate positions, users would need to setup a Liquidation configuration rule.
The Liquidation Engine uses the configuration rule to determine the method in which it should
calculate the positions for each security held and the realized and unrealized P&L.
In order to show you how Calypso addresses held Instruments, we will re-use an example of the
Equity trade (that was Position based), and walk you through the configuration showing only the
pertinent information required for this course.
To configure liquidation calculation to be applied on positions, navigate to:
Main Entry > Configuration > Books & Bundles > Liquidation
• Book: Using the dropdown, users can select ‘ALL’ or specific Book. In our case we have selected
our Equity Trading Book
345
Notes:
• Product Type / Subtype: As liquidation is Book + Product, using the drop down, users can select
‘ALL’ or refine definition of product as to its specific subtype. We have selected ‘Equity’
• Liquidation Config: Allows users to compute multiple positions for the same combination of book
and product type but with different liquidation methods, i.e., Book = Equity Trading Book / Product
= Equity can have Liquidation Method FIFO and another for Avg Price
This is helpful for clients that have global books and different accounting regulatory
accounting principles across their books.
• Comparator Method: This option tells the Liquidation Engine what to reference/compare when
Liquidating Trades
• TradeDate: The first level of comparison for the liquidation is the trade date and time, then the
Trade Id
• Manual: Select to process the liquidations manually, for example, with future and future option
products. This is used with Liquidation Method Manual
• SettleDate: The first level of comparison for the liquidation is the settle date, then the trade date,
and then the Trade Id
• SettleTradeDate: The first level of comparison for the liquidation is the settle date, then the trade
date, then Buy/Sell, then the trade date time, and finally the Trade Id
• TradeDateFixed: Use with liquidation method MFIFO - It allows filtering intraday trades by
comparing the trade date to the book EOD, then for non-intraday trades, it is the same as the
TradeDate comparator
• TradeDateStartOfDay: Take trade date into account without time. This was designed specifically
to work with the Liquidation Method WACSL
• TradeId: The first level of comparison for the liquidation is the Trade Id
• Liquidation Attribute: Allows users to add additional position aggregation levels
346
Notes:
If the list shown above is not available as part of your Comparator method, you can add them to
the sortMethod Domain Value.
.
If further position aggregation than book + product is required, then:

a) Position/Liquidation Key needs to be defined. Do this by double click the red ‘Liquidation
Attribute’ field and selecting the additional criteria’s of aggregation required.
b) Via Main Entry > Filters > Position Specification, create a filter specification applying you
Position/Liquidation Key in the field ‘Position/Liquidation Key.’
c) Using the ellipses button; select the Position/Liquidation Key created.
Position aggregation can be used for Accounting Purposes. Refer to the Calypso University
Fundamentals of Calypso Accounting course for configuration details “Sample Accounting by Position
Aggregation.
At the Trade Workflow level, Trade Workflow Rule CheckLiquidationAggregation can be added (at the
transition such as PENDING-AUTHORIZE-VERIFIED) and the rule will check if trade has the required
attributes set in order to correctly liquidate the trade per the liquidation aggregation configurations.
• Liquidation Method: Depending on Book & Product type, users can have different liquidation
methods per book
Below are the methods:

AvgPrice: Calculates across positions using the average price.
FIFO: Calculates based on First-In-First-Out liquidation method.
HIFO: Highest Price First Out liquidation method (only for Portfolio Swaps).
LIFO: Last In First Out.
MFIFO: Modified First-In-First-Out (Futures). This applies the FIFO method on intraday trades first,
then the standard FIFO method. The MFIFO method can only be used in conjunction with the
comparator method TradeDateFixed.
Manual: The Liquidation Engine maintains the open positions, but does not actually liquidates the
positions. The positions are liquidated manually.
347
Notes:
The above list of Liquidation Methods are Calypso’s out-of-the-box standard offers, if you would
like to add additional methods, you can do so by either customizing or using the ‘liquidatioinMethod’
Domain Value.
None: No liquidation is done.

• Valuation Method: Checking here only effects the EOD Back Office valuation process, i.e. when
using the Portfolio Manager and/or EOD_TRADE_VALUATION and
EOD_POSITION_VALUATION Scheduled Tasks
• Use Position Engine: If checked, the Position Engine for will be used for valuation instead of the
Liquidation Engine
This is used when you don't need to liquidate the trades, but only to aggregate them into
positions like FX-related trades. In this case, the Position Engine needs to be running.
• Value By Trade: If checked, then valuation is run on each trade that has not been liquidated
A TRADE VALUATION event is produced for each open trade. Otherwise there is a valuation
event by position.
• By Trade Date: this is not used
For Create:
• Fee Positions: If checked, this creates positions on fees attached to trades. The fee positions will
be maintained separate from the trade position
If Fee Positions is checked and users would like to see position including the fee, then once in
the Position Keeper main window, users will need to check the ‘Incl. Fees in Position’ checkbox.
• Fees Settlements amounts Positions: Check to create fee positions even if the fee is included
in the settlement amount. Fee positions will be maintained separately from the trade
Users define if a particular fee is included in the settlement amount by checking ‘Settlement
Amount’ when originally saving the Fee via Main Entry > Configuration > Fees, Haircuts & Margin Calls > Fee
Definition.
348
Notes:
• Snapshots: This checkbox will appear checked if a liquidation snapshot has been created for the
positions generated for that liquidation
Liquidation snapshots are created using the LIQUIDATION_SNAPSHOT Scheduled Task and
can be used by the EOD valuation process EOD_POSITION_VALUATION to improve
performance.
Products Recommended Settings
Liquidation Method = FIFO

Comparator Method = SettleDate
FX NDF, PLP Sweep, Position FX NDF
Value By Date = Unchecked
Use Position Engine = Checked
Liquidation Method = FIFO or AvgPrice
Position based products (Bonds, Equities, Comparator Method = TradeDate

ETO Equities, CFDs, etc.) Value By Date = Checked
Use Position Engine = Unchecked
Liquidation Method = MFIFO
Future products (Bond Futures, Bond Future Comparator Method = TradeDateFixed

Option, MM Future, MM Future Option) Value By Date = Checked
Use Position Engine = Unchecked
Determine EOD Date / Time

Because the Liquidation engine calculates positions using book + product, this is one of the reasons
(the other being for EOD Valuation purposes) that when setting up our Equity Trading Book (which is
our position based product), we had defined the End of Day Date/Time and Time Zone on our books.
Calypso (the Liquidation Engine) takes trades into account for positions, based on the End of Day
Date/Time and Time Zone of the books. This EOD Date/Time of the book determines when positions
in a particular book settle.
From a Back Office perspective, in order for the liquidation process to begin on the desired date/time
(i.e. as soon as the positions are deemed settled by the Engine according to the EOD Date/Time),
trading books need to have Date/Time and Time Zone stipulated.
In Calypso, there are in fact several ways to define the EOD Date/Time. The system will derive the
EOD time for position liquidation purposes (and later valuation purposes – covered during the
Calypso University Fundamentals of Calypso Accounting) in the following order:
• Using the ‘Variable EOD’ window from the ellipses button next to the Trading Book ‘End of Day’
field
349
Notes:
4 3
1. Click on the ellipses button next to the ‘Min’ field

2. Input specific EOD Date and Time (use HHMM) in the fields provided
3. Using arrows, move Date and Time to the right side of window
4. Click ‘Apply’
At the Legal Entity level, by using the LegalEntityEODTime window:
Main Entry > Configuration > Legal Data > EOD
2
3
1. Click on the ‘Legal Entity’ ellipses button and select the Legal Entity
2. In ‘Date’ field, input the specific ‘Date’
3. Using ‘Time’ field, input the Time (use the format HHMM)
4. Click ‘Save.’ This will add the defined configuration to the window
In the case above, the variable EOD for the specific date on a specific book has been set to
2200, so just for that book the variable EOD will override the LegalEntityEODTime.
5. Set the ‘End of Day’ Hour and Min fields on the Trading Book
350
Notes:
In the event that Comparator method in the Liquidation Configuration definition has been
set to TradeDateFixed:
The EOD Date/Time can be defined using the Trading Book attribute LiquidationTime. The format
should be HHMM.
• In this case, this attribute is checked first (and will override other settings) before
the system begins checking any of the three other EOD Date/Time configuration
setups.
351
Notes:
Should you require delayed Liquidation, you can set the engine parameter
LIQUIDATION_TIMEOUT to delay the actual liquidation of the trades to improve the performance
of the liquidation engine.
Business Logic
In Calypso, positions for position-based financial instruments are computed using the Liquidation
engine. By default, the Liquidation Engine performs liquidations between buy and sell trades by
keeping a record of the positions at the level of Book + Product Id aggregation level. As an option,
users can drill down further to refine their aggregations by using book + product + "whatever
additional user defined aggregation levels they deem necessary for their business.’’
The logic is that the positions for a given book and a given product (plus any other aggregation
added) are calculated for the trades requiring a position, according to defined liquidation
configuration. Technically speaking, for the Liquidation Engine to build/calculate/liquidate positions on
book/product (and other aggregation if required) trades do not have to be in any specific status. They
just need to be saved for the Liquidation Engine to capture the ‘Trade’ event.
This means the Liquidation Engine does not care if the trade is in PENDING status or VERIFIED
status and will start taking into account positions, trades that could in the end (in reality) not have
been ‘confirmed’ or otherwise regarded as (using the Calypso out-of-the-box Workflow) ‘VERIFIED’
status.
Filtering capabilities have been added recently (at the level of Liquidation Configuration)
to allow clients to determine which positions the Liquidation engine takes into account, i.e., this
allows client to build position using trades in PENDING status and another one excluding
PENDING.
Taking the same concept as the inventory engine, this is almost like allowing users to define a
‘theoretical’ Liquidation Position (using PENDING) vs. an ‘Actual’ Liquidation position (excluding it
and using VERIFIED etc.).
There is an exception to this for Future product’s/manual liquidation. For Futures/Manual

liquidation, having correct SDIs or not can impact the building of correct positions, thus in this
case, although it is not really the status of the Trade that plays a role, correct SDIs do and thus by
consequence (if on the Trade Workflow, ‘Check SDI’ rule exists), the trade will need to have
reached and passed this rule.
352
Notes:
The main purpose of using the Liquidation Engine to build, maintain and calculate positions in
Calypso is to allow the system to calculate the position of each security that an organization holds, to
show both the amount of the organizations holdings and their associated realized and unrealized
P&L.
The products handled as ‘Position based’ by the Liquidation Engine are those that have been
defined in Calypso core code with a flag ‘isPositionBased.’ Calypso also allows users to add to
that list via the postionBasedProducts domain value. Examples of these products are:
• Equity
• Bond
• Future
• Future Option
• CA
• Issuance
Trade Open Quantity

Now that we have understood that the Liquidation Engine builds, maintains and calculates positions
by taking into account the transactions that have taken place on a certain Book + Product, we can re-
introduce the ‘Conceptual Model.’
If you remember, we had reviewed a table showing the Calypso logic of separation of Trade &
Product. This was the table we had reviewed:
Trade Product
Trade Id (this would be the Bond Product id (this would be the system generated number):
system generated number):
Name: UST 10yr
Concerned Parties (Bank
Bond Type: UST 10yr Feb ’23 2.0 %
A/Counterparty A)
th
th Issue Date: 15 Feb 2013
Trade Date = 18 Feb 2013
Issuer: US Treasury
Quantity (buy/sell) = - 30mill
th
Maturity Date: 15 Feb 2023
Price = 100.965
Coupon Rate: 2.0
Currency = USD
Coupon Frequency: S/A
Trader Name = John Doe
Face Value: US$ 1000
Maturity Tenor: 10year
It is in this section that you can begin to understand the relevance of this table and its implications.
Although the table above showed you trade details of a Bond, the same logic would apply to our
Equity position based trade example.
353
Notes:
When a trade is input, the default behavior of the Liquidation Engine is to take some segment from
both the trade and from the product information (from the Trade Object transacted) and for each
Book/Product/Liquidation Config (and aggregation if specified) build, update and maintain positions.
The Liquidation engine does this by building an object in Calypso we identify as a ‘Trade Open
Quantity.’ The Trade Open Quantity allows the engine to compute and keep positions.
A transaction thus prompts the Liquidation Engine to:
• Build/Create open positions with trades that are not fully liquidated
• Updates old Liquidated Positions if there is any un-liquidation
• Update the Trade Open Quantity
• Calculate PL position
The table below defines the information put together by the Liquidation Engine to build the Trade
Open Quantity in the Data Model (database). The fields applicable to our Equity scenario have been
colored green.
As mentioned earlier in the Business logic section, with the exception of Futures/manual liquidation
cases, the Liquidation Engine does not require a trade to be in a specific status to build the Trade
Open Quantity position.
For Futures/manual liquidation, this is not the same because Calypso puts the account (Clearer
account) coming from the SDI as part of the related Id of the Trade Open Quantity. As a result,
having or not having SDIs may impact the Trade Open Quantity and can determine if one trade can
be liquidated with another Trade Open Quantity.
For Futures/manual liquidation scenarios, you might not be able to liquidate a trade in a particular
status and has SDIs with another trade that’s also in a particular status but has no SDIs, even if
they are in the same position.
In addition, for Futures to calculate the REALIZED position, Calypso requires transfers in
VERIFIED status.
Fields Description
Trade Id Identifier of the trade.
Product Id Identfier for the product.
Settle Date Settle date of the trade with the HH MM and time zone.
Trade Date Date of the trade with the HH MM and the time zone.
Quantity Original quantity. A negative number for Sell.
354
Notes:
Fields Description
Open Quantity Quantity left after different Liquidation processes.
Price Price of the trade at transaction.
Accrual Accrual of the trade.
Quantity put in Repo or Lent, or Borrowed (used only in LiquidationSecurity

Open Repo Quantity
and LiquidationBond).
Book Id Book of the trade.
Product Family Product Family from the product used in Trade
Product Type Product Type from the product used in Trade.
Flag to indicate if the TradeOpenQuantity is liquidable. True if Spot, else

Is Liquidable
false. The flag is updated by the ‘Timer’.
Only for Repo and Security Lending; to indicate the Trade Open Quantity is
Is Return
a return.
Return Date For Repo and Security Lending, return date.
Entered Date Entered Date of the trade with HH MM & Time Zone.
Position Keeper
The Position Keeper report is the report used to view the organization’s held positions. It allows an
organization to value its position based held positions and their relevant P&L as well as giving users
the means to compare accounting positions and valuation results.
Before being able to generate and view positions in the Position Keeper, in addition to the Liquidation
Engine subscribing to the PSEventTrade, defining the Liquidation configuration for book/products,
determining the relevant EOD Date/Time desired, users must also ensure:
• The Transfer Engine is running
• The Liquidation Engine is running
Main Entry > Market Data > Market Quotes > Quotes
355
Notes:
If the Pricing Parameter

used in the Pricing
For Environment
correlation, Configuration (in this
refer to the case, ‘default’) the
Pricing Pricing Parameter
Environment INSTANCE_TYPE is set
dropdown to CLOSE, then you can
in the just update prices in the
Position ‘Close’ column.
Keeper
window.
For each market day during which positions were held, closing price quotes have been saved (to view
P&L). This must be the quote set attached to the chosen pricing environment of the Position Keeper
report. Having configured all the necessary fields mentioned above, users can access the Position
Keeper report by navigating to:
Main Entry > Positions & Risk > Position Keeper
Configuration
Using our Equity trade example, below we will go through some of the report configuration fields.
As most reports, in the top section of the Position Keeper report, the report consists of selection
criteria.
356
Notes:
• Val Date: The date in this filed allows users to indicate the date user would like to view his/her the
positions for
When the Position Peeper opens, by default the ‘Real Time’ checkbox at the bottom left of the
window (view screenshot below) is checked.
The date showing in the Val date is automatically adjusted to system date. If the date is today, then
you will see the positions as of ‘now.’ Should any other date than current date is required, users would
need to uncheck the ‘Real Time’ box and input the date/time required. The system will show positions
as of that date.
To view position for our Equity trade example (trade date 19th March 2012, thus Trade Open Quantity
built on 19th March), uncheck the ‘Real Time’ and input 19th March and the trading book Equity
Trading Book’s EOD time (screenshot below).
357
Notes:
• Trade Filter: This drop down allows users to display positions made up of only the trades in a
predefined trade filter
Trade filters need to be configured via:
Main Entry > Configuration > Filters > Trade Filter
• Product: Using the ellipses button, open the Product Chooser window. Users can choose one
specific security for which they want to display the position
• Pricing Env: This drop down allows users to choose the Pricing Environment containing the
quote set that will be used to compute the P&L on the position
For this case, the quote set will be coming from the pricing environment named ‘default’ where closing
prices (instance = ‘Close’) will be used. Refer to Quote window screenshot above.
Pricing Environments need to be configured via:
Main Entry > Market Data > Pricing Environment > Pricing Environment
• Hierarchy: The Hierarchy drop down allows users to filter positions displayed in this report
according to preconfigured book hierarchies. This would allow users to drill down using a book
hierarchy to see which books (and hence trades) are responsible for changes in position.
Selecting a Book Hierarchy is not mandatory
As an example, we have preconfigured some book hierarchies (at the Legal Entity level and at the
Location level) via:
Main Entry > Configuration > Books & Bundles > Book Hierarchy
358
Notes:
From the Position Keeper, when you select a hierarchy, it will appear as a tree view in the pane
occupying the left side of the window.
359
Notes:
OR
Each node generally corresponds to a part of the organization or types of trading the financial
institution does. To display the positions of any node in the hierarchy, users would have to double
click on the node in the tree view. Positions will show on the right hand of the window.
• Aggregation: Users can display positions aggregated by attributes with respect to the hierarchy
chosen. These attributes are attributes of books defined in the Book window
• Zero Position: Using the drop down, the Position Keeper allows users to determine which
positions they would like to see
This logic is directly linked with the P&L position.
• Include: if selected, shows all positions, even if

the position is 0 positions.
• Exclude 0 nominal/0 P&L: if selected, the
loaded positions will include 0 positions (0
nominal) that may still have realized P&L BUT
exclude 0 positions that DO NOT have P&L.
• Exclude 0 nominal: If selected, this excludes
all 0 positions P&L or not.
This selection applies across all tabs in the Position Keeper report and can be very useful to control
the position’s users view in the Position Report.
For example, let us assume you have an aggregation level set to ‘Counterparty.’ In the event you
have positions across two counterparties (same amounts and same prices).
360
Notes:
The Liquidation Engine would have created Trade Open Quantity for these two positions (one with the
first Counterparty and another for the second Counterparty). Thereafter assuming one of the
counterparties was incorrect and thus trade amended and changed from the original Counterparty to
the other Counterparty.
The result would be that there is no P&L change. In the case where ‘Real Time’ is checked and
Unchecked, the Position Keeper would show:
• Include: user would view both positions. 0 nominal and nominal with updated amount for
Counterparty A
• Exclude 0 nominal with 0 P&L: user would view 1 position (Position with Counterparty A and 0
position of Counterparty B would be filtered out)
• Exclude 0 nominal: user would view 1 position (Position with Counterparty A and 0 position of
Counterparty B would be filtered out)
To give another scenario, assume you the event you have offsetting trades (buy/sell of same amount)
with the same Counterparty, but with Price difference thus resulting in P&L.
The result would be that there is P&L change. In the case where ‘Real Time’ is checked and
unchecked, the Position Keeper would show:
• Include: user would view both positions. The flat position and another position with P&L
• Exclude 0 nominal with 0 P&L: user would see only the position that has P&L
• Exclude 0 nominal = user would not see anything. 0 Position is filtered out and P&L is also
filtered out as this has no nominal and only P&L
For Position by Settle Date:

• Inc. Fees In Position: This checkbox only applies if fee positions are computed (Fee Positions
checkbox is checked in the Liquidation Configuration). If checked, the fee positions are
aggregated with the parent position
For example, let us assume you have a fee associated with the Equity trade. Let us say this is an
execution fee of some sort to be paid out to a broker. Should that be the case, when the trade with the
fee associated with it is booked, the below configurations should be in place:
• ‘Fee Positions’ checkbox is checked as part of the Liquidation Configuration
• Pricing Parameter has NPV_INCLUDE_FEES set to ‘true.’
To do this navigate to:
Main Entry > Market Data > Pricing Environment > Pricing Parameter Set
Calypso would calculate the fee P&L associated with the fee amount in a separate column and the
position calculated for the Equity trade would be also in a separate column.
• The ‘Incl. Fees in Position’ should be checked on the main Position Keeper window
• The trade filter used in the Position Keeper has CA included as part of the Product Family
361
Notes:
Then, Calypso would combine the two positions (Equity and Fee) into one and the total P&L shown
will contain with the financial instrument would be with the fees.
When the fees are aggregated with the parent position, you can right-click a position and choose
“Show Fee Position” to view the fee positions.
To show the Trade Open Quantity positions and the P&L calculated by the Liquidation Engine based
on the liquidation rules specified in the Liquidation Configuration, users can go to the Tools menu
(view screenshot) and define their desired user-defined position panels/tabs via the
‘PostionConfigTabs’ window.
As per the below screenshot, you can see that by default Calypso’s out-of-the box Position Keeper
comes with a predefined ‘ALL’ tab.
To review how users can configure their tabs, we can take the example of the configuration done for
our Equity security.
The right pane

shows all the
configurations done
for the particular
tab selected in the
right pane.
362
Notes:
• Using the ‘Tab name’ field, input the name of the tab as you want to see in the Position Keeper.
In this case, ‘Equity’
• Click on the ‘Add’ button so that the ‘tab name’ can be added to the left side of the
PositionConfigTabs window pane
• If you wanted to delete a tab, you would highlight the tab name showing in the left side of the
PositionConfigTabs pane and when it appears in the ‘tab name’ field, click ‘Del’
• Using the ‘Books’ ellipses button, when the Book selection window opens, using the
arrow right button and select the relevant book desired that should be filtered. Move the
desired Trading book from the left side of the window to the right
• Using the ‘Products’ ellipses button, in the product selection window, use the arrow right
button, select the relevant Product to be filtered in the position keeper tab (in our case the
Equity product). Move the Product from the left side of the window to the right
363
Notes:
• In the same fashion as the above examples, to view specific ‘Contracts’ (if applicable to the
product chosen above), the user would click on the ‘Contracts’ ellipses button and use
the selection window to select the relevant contracts. This would be useful in the case of Bonds or
Future products for example. In this case, we have not configured anything
The same configuration scenario would need to be applied to select the Columns to be viewed in the
tab.
If fixed columns are required, users would need to define them via the ‘Fixed Column’ eclipse.
Configure them in the same fashion as above. For our equity, none have been configured.
364
Notes:
If Static Data is needed as additional filter criteria for the tab being configured, then the Static Data
filter eclipse would need to be used. For our Equity, nothing has been configured.
Contrary to the Include/Exclude 0 Nominal cases on the Position Keeper (which was added
specifically to look at the P&L Position) criteria section, checking the ‘Open Trades Only’ will
determine that the results look at the underlying Trade Open Quantity.
For example, let us assume on a certain book + product, there is a BUY 10 Equity and a SELL 10
Equity:
• PL Position = Realized 0 Nominal 0
• Trade Open Quantity for buy trade = Open Quantity 10
• Trade Open Quantity for sell trade = Open Quantity -10
And you haven't liquidated these against each other for some reason (e.g. you're doing manual
liquidation). The 'Open Trades Only' would not disqualify this P&L position, as both Trade Open
Quantities have non-zero open quantities, but Exclude 0 Nominal or Exclude 0 Nominal/0 PL would.
• To activate all changes, amendments and updates, the ‘Save/Apply’ button needs to be clicked
The ‘Load’ and ‘Close’ buttons in the PositionConfigTabs allows a user to load previously
configured tabs and also to close configuration window (respectively).
365
Notes:
Viewing Positions
After configuring the Position Keeper as shown in the example above, let us now review (based on
our configuration) how our Equity transaction would be represented within the Position Keeper.
Column Description
Book The trading book associated with the position (obtained form the
transaction).
Unique product identifier created by system to represent the financial

Product Id
instrument involved in the transaction.
Position Id Unique Trade Open Quantity Id generated by the Liquidation Engine.
Text description of this row's financial instrument obtained from the

Description
product.
ISIN ISIN related to the product.
Quantity Displays the total Trade Open Quantity of the position.
Amount Total settle amount for the position.
Currency The currency of the position.
ISIN ISIN related to the product.
Current Mkt Price Market price based on the latest quote saved in the quote set.
The average price of the open position (position that is not liquidated).
Note that average price calculation is based on the product’s
Average Price liquidation method defined at the Liquidation Configuration level.
In our case as we only have one Equity trade, Avg Price will be price of
trade itself
The realized profit or loss on the position.

Realized Realized for FIFO and LIFO: (Second Price – First Price) * Quantity
Realized for Average Price: (Second Price – Average Price) * Quantity
366
Notes:
Column Description
Profit or Loss realized if the position was to be closed at the current

market price.
Unrealized Calculation = multiply open positions quantity by the difference
between Avg Price and the Currency Market Price.
In our case, (4,8 - 3,7)*50 = 55
Net profit or loss on this position, including both realized and

P&L
unrealized.
Liquidation and Details

Further information on the position presented can be obtained by:
1. Double-clicking any position to open the Trade Open Quantity window to inspect that position
If there have been any liquidations transacted on the position since its inception, the
Liquidated Positions table in the top of the window will display all of them.
2. In the bottom ‘Open Positions’ section of the window, users can see the remaining open position, if
any
Double-clicking an open position will open position to see the corresponding trade details.
367
Notes:
• Right-clicking a Position will access the Position Menu
• Much like double-clicking a position, selecting the ‘Show Liquidated Position’ menu will open the
Trade Open Quantity window
• Selecting ‘Show by Settle Date’ opens up the Position By Settle Date window (view screenshot
below) for the particular Position, allowing users to review positions by settle date in a report
fashion
368
Notes:
• The ‘Detail Position’ menu opens up a window to show either Trading Position or position divided
into Trading, Security Lending, Borrowing and Collateralized (the latter is dependent on report not
being real-time and the OPTIMIZE_LOAD_LIQ environment property being set to ‘false’
• Clicking ‘Show Liquidation Config’ opens a pop-up allowing users to have a quick glance at the
Liquidation Configuration applied on position
369
Notes:
• The ‘Manual Liquidation’ menu is only active if the Liquidation Method defined at the Liquidation
Configuration level is set to Manual (i.e. for Future products). Otherwise (not the case in our
configuration) when menu is clicked, system will throw an error like the below
• The ‘Trade’ menu would open up the trade window where position still exists with a counterparty
set to NONE
This could be useful, for example, in the occasion that users want to sell or transfer their entire
position to someone (e.g. internal legal entity) or close the position/reopen it (manually).
The latter (manual) could simplify archiving since users do not have to think about old trades that are
still part of the position. Some clients use this functionality to move positions around to other entities
during the day (e.g., for FX products). The rational being they could perhaps not want to have a
significant FX position anywhere, e.g. Singapore, "overnight" (night in Singapore) while turbulences
happen on the next continent (e.g. Europe), for risk reasons.
In the event that there are fees attached to a position, when ‘Incl. Fees in Position’ checkbox is
checked and the ‘Show Fee Positions’ is selected, the menu will open the underlying fee positions
attached to the Trades contributing to the Trade Open Quantity.
Liquidated Position Example

You can show how the Liquidated position will affect your Position Keeper and Trade Open Quantity.
At the transaction level, assume you had an offsetting trade input after the original purchase trade.
For the same book/product, input a sell of 50 Peugeot shares at price of 4.
370
Notes:
1. Reload the Position Keeper report

For Equity Product id 5901, even though the nominal is 0 as there is PL position, the Position
Keeper will update to show the latest Trade Open Quantity and P&L.
2. As Liquidation Configuration is to Liquidation Method FIFO, for Realized P&L, the Liquidation
engine would apply (Second Price – First Price) * Quantity. Thus, (4 - 3.7)* 50 = 15
Trade Open Quantity window would be updated to show the Liquidated Position
section/latest activity.
371
Notes:
• First Trade id: Identifies the first trade Id (the original buy trade)
• Second Trade Id: Identifies the second trade id (the sell trade input for example purposes to
offset position)
• Type: Identifies if it is a regular Liquidation (Buy/Sell) or a special one (Borrow,Repo,Lending)
• Quantity: Quantity liquidated
• Nominal: Nominal liquidated
• First Price: Price of the first trade. Negative number for Sells
• First Accrual: If applicable to asset class, this represents the Accrual of the first trade
• Second Price: Price of the second trade, negative number for Sells
• Second Accrual: If applicable to asset class, this represents the Accrual of the second trade
• Date: Latest Trade Date of the two trades
• Realized: Calculated based on the Liquidation method (FIFO) specified as part of the Liquidation
configuration
• Effective Date: The Settle date of the second trade
• Clean Realized: Calculated based on the Liquidation method (FIFO) specified as part of the
Liquidation configuration
At the database level, Calypso will have accounted for the two positions.
372
Notes:
Modifications Liquidation Handling

Undoing Liquidations
When a trade with a trade date prior to the last liquidation date is validated, the system will undo all
the liquidations done from this given date (according to the Liquidation Configuration, the comparison
will be made with the entered date or the last Liquidation date).
These trades with Open Quantity available will be integrated in the next Liquidation process.
Canceling Liquidated Trades

When a trade that is already liquidated is canceled, the engine will run the complete un-liquidation
process; it means that the Trade Open Quantity for the remaining trade is re-calculated, the
Liquidated Position is flagged as deleted for this pair of trades and the P&L position is calculated.
At the end of the task, an Unliquidated-Position Event is published. Modifications on a liquidated trade
may also generate an un-liquidation process. For example, when a user changes the settlement date,
the trade price or the quantity.
Any changes in the following fields will trigger an un-liquidation:
• Product
• Book
• Settle Date
• Trade Date
• Entered Date
• Price
• Quantity
373
Notes:
8.5 EOD Batch Processing

As discussed at the beginning of this course, one of the Back Office Operations users’ responsibilities
is to run End-of-Day (EOD) processes.
To help address this, the EOD processing in Calypso is conducted by scheduled tasks. To
accommodate the wide range of functionalities that need to be run, Calypso offers a full range of EOD
Scheduled Task processing capabilities, including but are not limited to:
• Running mark-to-market, P/L and risk reports
• Generating account statements or other means of communication
• Processing trades in bulk (ex. Maturing, Exercising)
• Reconcile positions per book/desk
• Sending accounting entries to the main G/L system overnight
• Running reconciliation reports
• Publishing Scheduled Task Events in order to be processed by other processes
• Importing & Running external batch jobs
• Importing and saving the EOD Market data
The system scheduled tasks functionality allows organizations to schedule and run their required
batch jobs at their pre-defined, organization or business driven times. EOD batch jobs (Scheduled
Tasks) are executed by the Scheduled Task window, but if required, can be executed on-the-fly.
The results of scheduled task executions are displayed in the Report panel of the Scheduled Task
window, and in the event of exceptions, logged into the Task Station. Custom exception handlers can
be implemented for failed scheduled tasks to restart the scheduled task or to fix the error.
Timing Features of Scheduled Tasks

Below is a reference list of features that are shipped out-of-the-box with Scheduled Tasks.
• Scheduled Tasks are designed to run without having to shut down the system for end-of-day
processing
• They may run 24 hours per day, seven days per week
• Scheduled Tasks may be executed just for a given processing organization and at a given time in
the system, while the daily operations are run for another processing organization
• Calypso takes time zones into account for multiple branch (PO) businesses, allowing end of day
processes and trading to run in parallel, in multiple time zones
• Multiple Schedule Tasks may be ‘chained’ together and run in series. Each task in the series can
be setup to run only when the previous task completes
• A valuation Date time may be applied to control that sets of market data and quotes are to be
applied in a reporting analyses
374
Notes:
Generic Review of Scheduled Task Setup

To configure a Scheduled task, navigate to:
Main Entry > Configuration > Scheduled Tasks > Scheduled Tasks
• To save a scheduled task, click the ‘New’ button located at the bottom of the Scheduled Task
window in the Definition panel
• The ‘Type’ on the top left window allows you to select the type of scheduled task from the drop
down field
In the event that the Scheduled Task is not available from the ‘Type’ field, you can add it to the
ScheduledTask domain by going to Main Entry > Configuration > System > Domain value
You can also review Calypso Documentation for further details on how to add Scheduled Tasks.
• The Description field is free format for describing your desired operations use for this particular
scheduled Task. This can be useful in the event you have the same scheduled task saved several
times with different attributes; the description could help to differentiate one from another
375
Notes:
• The Processing Org drop down allows you to select your PO for which your scheduled task will
run
• The Trade Filter drop down allows you to select a trade filter that corresponds to the time of
scheduled task you are running for your PO. This limits the scope of trades/positions/books, etc.
that the scheduled task is running for. This is mandatory for position based products
• You will need to select a pricing environment using the Pricing Env drop down
• User drop down allows you to select the user whom will be responsible for the scheduled task
completion
• In the event that you have Pricer Measures that need to be applied when the scheduled task is
run, select the radio ellipses to the right of the ‘Measures’ sign and the Pricer Measure
window will allow you to choose the appropriate ones
• Once the scheduled task is saved, the system automatically updates the Ext Ref using a name
derivative of the Scheduled Task type and a number. You can also enter a user-defined external
reference as needed
• Time Zone indicates the time zone where the scheduled task is to being executed
• Should you desire to adjust the valuation date from the current date, you can enter the number for
offset using the Val Date Offset. Valuation date = current date - offset. For example, an offset of 2
indicates that the scheduled task will use market data from 2 days ago
• From Days/To Days are means by which you can enter the number of days away ‘from’ valuation
date and ‘to’ valuation date. The From Days compute the start date from the valuation date i.e.,
Start date = valuation date - from days. The 'To Days' computes the end date from the valuation
date. End date = valuation date - To Days. For example, today is 6th July. Val Date Offset is 1
and From Days/To Days is 5/2. The valuation date is 5th July, start date is June 30, and end date
is July 3rd
• Valuation Time indicates when the market data will be retrieved on the valuation date. The time
format used is the same as the Exec Time where 24 hour and 00 minute will represent
23:59:59:999. When the scheduled task is run, the Val time which appears in the pop up window
(shown below) is based on the below
376
Notes:
• Click the Holidays radio ellipses button to select a holiday calendar to apply to your
scheduled task. The holiday will determine the start and end date of the output from the
scheduled task
• In order to be able to execute the scheduled task on the fly you will need to check the ‘Execute’
checkbox
• Check to publish a scheduled task event when the scheduled task is completed. This allows
triggering other processes
• For example, for the RATE_RESET, OPTION_EXERCISE, and CORPORATE_ACTION

Scheduled Tasks, the corresponding windows will open in the environment of the selected user
• Set the attributes of the scheduled task based on its type
• Click the ‘Save’ button at the bottom of the Scheduled Task window to save your scheduled task
configuration
Calypso APIs allow for the creation of user-defined Scheduled Tasks.
Back Office Related Scheduled Tasks
• INVENTORY_SNAPSHOT Scheduled task = creates an inventory snapshot at a given time using

the inventory position
• RECONCILE_INVENTORY Scheduled task = allows users to perform an inventory reconciliation

on a regular basis
• To update the settle date on a failed transfer, you can run the scheduled task
RECON_INVPOSITION and it will modify the settle date of your failed transfers to the next day
• CHECK_LIQUIDATON Scheduled Task = updates Trade Open Quantity position to fix liquidation
changes/calculations
377
Notes:
Course Exercises
Course Exercises Introduction to Calypso Back Office
Module 2 Exercises
System Architecture & Trade Design
A. Data Base, Data Server / Event Server & Engines
1. What happens if a Trade is saved and the Message Engine is not running?
2. What happens when the Message Engine is started?
3. What happens if during the processing of an event, an engine shuts down?
4. In the Publish-and-Subscribe communication, does the application that creates the event need to
know who will receive the event?
5. Explain briefly how the P&S communication works (i.e. what publishes and who is responsible for
the subscription communication).
B. Applications & Reports
6. Can reports subscribe to events or is it only engines?
7. If applications that are not engines subscribe, should real time checkbox be checked or
unchecked?
C. Conceptual Model
8. Why does Calypso have the separate design model of Trades & Product?
9. What two category of Product modelling can Calypso Support and give example of a product for
those categories?
10. What role is given to define your Organization in Calypso?
11. How is the facing counterparty represented in Calypso?
12. Can a trade be a transaction of many products?
379
Notes:
Module 3 Exercises
Access Permissions, Static and Reference Data
A. Hands on Class Exercise: Configure User
Main Entry > Configuration > User Access Control > Access Permission > User
a. Select ‘’New’’ button
b. Add user name via ‘’Full Name’’ Field = <your first name>
c. Select Group via the ellipsis ‘’Select Group’’ and choose ‘operational’
d. Using the field ‘Password,’ add your password <your last name>
e. Use the button at the bottom of the screen to ‘Save.’
B. Group Access and Book Access

Main Entry > Configuration > User Access Control > Access Permission > Book
If cm_trader has;
• Group Access for ‘SaveTrade’ under the ‘Function’ heading.
• Group Access read/write to the Trading Book ‘Equity Trading Book’ under the ‘Book’ heading.
• Group Access read/write to the Swap and Equity Product type,
• Group Access read-write to a static data filter that contains the Swap.
• Book Access for Equity Trading book with permission to trade USD currency.
• Book Access for Equity Trading book with permission to trade Swap Product
Question:
Using the scenario above, at this stage can user ‘trader x’ as part of cm_trader group trade a USD
swap using Equity Trading book? Give reason.
380
Notes:
C. Hands on Class Exercise: Setup own Processing Organization

a. At bottom of page, click ‘New’ Button
b. Using ‘Short Name’ field, input ‘Training_PO’
(Note: Short name input when saving will identify LE throughout the system)
c. Using ‘Full Name’ field, input ‘Training_ProcessingOrg’
d. In the Status Field drop down, select ‘Enabled.’
e. At the button of the ‘Role’ box, use the ellipsis button to open the ‘Select LegalEntityRole(s)’
window and choose the role ‘ProcessingOrg’ from the left section of window to move it to the right
section (using >> arrows) and press ‘ok.’
f. In the ‘Country’ field, select France
g. Using the ‘Save’ button at the bottom of the screen, save your configuration.
D. Hands on Class Exercise: Setup Processing Organization ‘Contact’

a. From Legal Entity window, using the ‘Load’ button at the bottom left of the window, open the
Legal Entity Chooser window and in the ‘Short Name Like’ field, input your PO’s short name
‘Training_PO.’
b. Click ‘Enter’ on your computer after typing your PO’s short name
c. When your Legal Entity appears in the table to the right, double click your PO to select it.
d. After your PO has loaded in the Legal Entity window, using the buttons under the comment field
on the Legal Entity window, select the ‘Contact’ button.
e. When the Contact Window opens (ensuring that the Legal Entity field on the top left of the window
is your PO’s name), navigate to the top right of the screen and using the drop down of the
‘Contact Type’ field select the Contact Type Back-office.
Define the below remaining fields as per the below instruction:
• Last Name Field = <your last name>

• First Name Field = <your first name>
• Address Field = <your company’s address>
• City Field = <the city of your company>
• Country Field = <France>
• Phone Field = <your telephone number>
381
Notes:
• Swift Field = <TESTINGBANKS>

• Email Field= <your email>
f. Using the ‘Save’ button at the bottom of the Contact window, save your configuration.
E. Hands on Class Exercise: Setup Trading Book

Main Entry> Configuration> Books & Bundles > Trading Book
a. Click on the ‘New Button’ at the bottom of the Book window.
b. Using the ‘Name’ field input your trading book name <Main Trading Book>
c. Leave ‘Activity’ field blank
d. Using the ‘Accounting Link’ drop down, select CALYPSO UNI BANK.
e. Using the ellipsis to the left of ‘Legal Entity’ field, open the Legal Entity Chooser window and in
the ‘Short Name Like’ field, input your PO’s short name ‘Training_PO.’
f. When your Legal Entity appears in the table to the right, double click your PO to select it.
g. Back in the Book Window, using the ‘Location’ field, input your location i.e., <Europe/Paris>
h. In the ‘End Of Day’ field: input 23 for the ‘Hour’ field and 59 for the ‘min’ field
i. In the ‘Base Ccy’ field, select <EUR>
j. Using the ellipsis to the left of ‘Holiday,’ select <PAR> from left section of the Select Holidays
pop-up and move it to the right side of the pop-up before applying ‘ok’.
k. Using the ‘Save’ button at the bottom of the Book window, save your configuration
382
Notes:
Module 4 Exercises
Components of a Trade
A. Trade, Transfer/Message & Postings

1. What are certain aspects of a trade that remain somewhat generic?
2. Does a trade go through various stages / checks and / or additions before recognized to be
officially booked / verified and / or confirmed and if so give an example of a check?
3. Who and what determines the stages of checks / verifications to be done at a Financial
Institution?
4. Once booked does the totality of the stages a trade go through depend only on the business
practise of the institution?
5. What is the name Calypso gives to the moving of a Trade across these stages?
6. When are the main Back office components (transfer/message/posting) generated? And is this
configurable?
7. On the trade window, from where can we access the main (transfer/message/posting) Back office
components?
8. What is a transfer?
9. What are the two delivery types Calypso assigns transfers?
10. What do these two delivery types stand for (what do they mean) and give an example of transfers
that fall into each delivery type?
11. Using the two trade examples shown in class, name the different Transfer Types (flow types)
shown that represent Cash and / or Security Movement?
12. What are the four categories (Event Types) that calypso assigns each Transfer Type generated
and what are they dependent on?
13. What does Calypso use the term ‘Message’ to mean?
14. What is the purpose of a message?
383
Notes:
15. Give an example of some types of messages?
16. If there are any discrepancies during the message confirmation process, what is required of a
back office user?
17. Messages can be in various formats. Please give an example of any two format types?
18. Does the type of message generated (MESSAGE_TYPE) depend on the Event that caused it?
19. Using the example of our two trades, in the below table: please fill in the missing trade related
and transfer related Message Types generated along with an explanation as to whom they were
generated and for what purpose.
Trade Related
Product MESSAGE_TYPE To whom & Purpose
Equity
Swap
Transfer Related
Product MESSAGE_TYPE To whom & Purpose
Equity
Swap
Swap
20. Why do Financial Institutions need to generate accounting entries?
21. Give an example of some trading and processing actives that Calypso generates accounting
entries for?
22. Give two examples of why in general, accounting methods may very?
384
Notes:
Module 5 Exercises
Generation and Breakdown of Components
A. Hands on Exercise: Save an SDI for your Processing Organization
Navigate to:
Using ‘Load’ button, when the Legal Entity Chooser opens, load your previously saved PO =
Training_PO
Once you have loaded Training_PO Processing Organization, save an SDI to be linked to this
Processing Organization following the below instructions:
a. To open the SDI window, click on the ‘SDI’ button.
b. Go to the ‘Edit’ tab.
c. For the field ‘Role’ use the drop down to select ProcessingOrg.
d. For the ‘Beneficiary’ field use the ellipses (when the Legal Entity Chooser opens) to select your
‘Training_PO’ Legal entity.
e. On the top right of the window for the ‘Contact’ field use the drop down to select ‘Back-Office’.
f. For the ‘Method’ field use the drop down to select ‘SWIFT’.
g. In the middle right of the window, where you see the checkbox ‘Preferred,’ check this box.
h. Towards the bottom of the window in the ‘Agent’ tab, under the ‘Code’ field use the ellipses and
when the Legal Entity Chooser opens select ‘CHASE NY’.
i. In the ‘Agent’ tab, for the ‘Contact,’ use the drop down to select ‘Payments.’
j. In the ‘A/C’ section input ‘1234’ as an account number.
k. Below the A/C field, in the ‘GL A/C’ field use the ellipsis button and when the Legal Entity
Chooser opens select ‘TRAINING NOSTRO Account.’
l. Save
385
Notes:
B. Hands on Exercise: Set up message Config for your PO – (for Swap & Equity)
Navigate to:
Main Entry > Configuration > Message & Matching > Message Setup
a. Navigate to the ‘Edit’ Tab at the top
b. From the list of POs on the left hand tree branch, highlight PO: CUB and double click.
• You should get a pop up asking you if you are sure to load all existing setup for any receiver.
Select ‘Yes’
• This will load the existing message configuration for the PO:CUB within the edit tab in the
table below.
c. From the main Edit tab, at the bottom of the page, select the ‘Duplicate’ button.
d. Using the ‘Duplicate’ pop-up, select ‘Processing Org,’ then apply the ‘Ok’ button.
e. When the ‘Processing Org Copy To’ pop-up appears, from the list in the pop-up, select your
Training_PO Processing org and apply the button ‘OK.’
• You should get a pop up asking you if you are sure to copy loaded configs to Training_PO.
f. Select ‘Yes’
386
Notes:
global · dynamic · world-class
www.calypso.com
For more information, email: calypso_university@calypso.com
© Copyright 2013 Calypso Technology, Inc. All rights reserved. Calypso is a registered trademark of Calypso Technology, Inc. in the United States, European Union, and
other jurisdictions. All products and services referenced herein are either trademarks or registered trademarks of their respective companies.No part of ths publication may
be reproduced or transmitted in any form or by any means, including but not limited to, conversion into any electronc format, without the written permission of the copyright
holder, application for which should be addressed to Calypso Technology, Inc.

CalypsoTraining PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CalypsoTraining PDF

Uploaded by

Copyright:

Available Formats

©2013 Calypso Technology, Inc. All Rights Reserved.

Training for Intesa Sanpaolo and

10-11 September 2013

Using the Training Manual

Additional Research - Any additional information or research that is related to

Comment - Any tips, suggestions or comments will be preceeded by this icon.

• Static Data Filters – V12+

Module 1 Back Office Overview

Day Module 2 Calypso Design and Architecture

• Conceptual design of trades in Calypso

• Required standard data

Module 3 Access, Static Data, and Reference Data

• Trading Books and Accounting Books

Module 4 Components of a Trade

• Trade component: Transfers

• Trade component: Messages

Module 5 Generation and Breakdown of Components

• Generating Messages: Message Engine and Events, Message Configuration

• Legal Entity contact information

• Accounting Postings: Account Engine and Events, link between Accounting

Module 6 Workflow – Lifecycle of Components

• Workflow Configuration: Straight-Through Processing

• Implementing the 4-eyes principle through Workflow

Module 7 Monitoring and Managing

• Task priority levels

• Distribution of management of tasks of various priorities across users

• Task Activities: Taking ownership, adding comments on underlying objects,

Module 8 Component Reports, Position Monitoring and EOD Scheduled Tasks

• Describe Scheduled Tasks for EOD jobs

Final Assessment, end of Day 2

• Explain the role of Back Office departments in financial institutions

• Identify the daily and periodic responsibilities of Back Office

Straight Through Processing

1.1 Preliminary Operations Prior to Back Office

Milestones in a Typical Trading Day

Risks in a Typical Trading Day

1.2 Back Office Operational Responsibilities

• Review overnight issues

• Confirm financial details

• Confirm generation of flows

• Verify confirmation with counterparty

• Confirm settlement details

• Investigate funds not received

Trade Processing in General

Rate Resetting/Price Fixing

• Automated or manual capture of quotes/prices

• Input official market data: FX Fixings, IR Resets

Margin Call Management

End of Day (EOD)

• Monitoring of position held and running Mark-to-Market and P&L reports

• Reconcile positions per book/desk

• Send account postings to the main GL system overnight

• Monitor FX – payment deadlines

• Futures/Options – broker statement reconcile (trade checkout)

• Reconcile P&L and positions with Front Office

Static Data Maintenance

Monthly/Yearly Official Statements

• Termination (upon agreement with Counterparty)

• Exchange Traded Option Exercise

• Future Expiry (affects positions, P&L, Postings)

• Trade transfer – trades moved between books and Counterparties

• Position Transfer – Transfers an entire position for settled trades

• Describe the Calypso architecture