Back Office Overview
The Calypso workflow allows carrying out any back office activity by automating back office operations using straight-through processing (STP), provided a number of conditions are satisfied. The idea is that the user will only intervene in the case of an exception (an error or a special case).
The workflow defines the lifecycle of an object: trade workflow, message workflow, transfer workflow, etc. Workflows are configured by processing organization and product type. A workflow is composed of tasks that promote an object from a given status to another status through a given action. The task can use STP with conditions, or can be manual.
The way it works is that a number of engines are running in the background, and they are reacting to the various events that occur on the system. For example, a trade is saved, a quote is saved, a payment is settled, etc. Based on these events and the configuration of the workflow, new events will be generated: a confirmation, a payment, a posting, a position, etc.
The workflow in itself is managed by the Data Server and does not require any engine to be running. However, if you are setting workflow tasks with kick-off timers and cut-off alerts, you need to run the Task engine.
The following back office engines are available:
| • | Generation of Messages – Message engine |
| • | Sending of Messages – Sender engine |
| • | Import of incoming messages and matching – Import Message engine, Matching engines |
| • | Generation of transfers, payments, and netted payments – Transfer engine |
| • | Generation of accounting postings – Accounting engine |
| • | Generation of CREs (Account Enrichment events) – CRE engine |
| • | Sending of CREs – CRE Sender engine |
| • | Generation of inventory positions – Inventory engine |
| • | Generation of management fees – Billing engine |
| • | Generation of P&L positions – Liquidation engine, Position engine |
| • | Processing of scheduled tasks – Calypso Scheduler |
All of these processes are described below.
Contents
1. Trade Workflow
The trade workflow allows defining the lifecycle of a trade.
Sample Trade Workflow
The basic action of creating a trade is represented by the transition NONE - NEW - <any status>.
The trade workflow is configured by processing organization, and product type.
At any point of a workflow, a message can be generated and the message workflow takes care of it: a message can be sent, acknowledged, matched, etc.
The trade lifecycle functions of the trade workflow are described in the user guides per asset class.
2. Message Generation
The messages functionality is two-fold:
| • | Generation of messages and associated physical/soft documents |
| • | Processing of incoming messages |
A message identifies any document or payment that you send/receive to/from an organization (including contacts within your organization) to alert them about an event that has occurred on a trade, payment, position, etc.
The generation of messages is a two-step process:
1. The message engine generates messages based on message configurations and contact information. A message follows its own workflow, and is associated with a physical document generated according to a template. The physical document at this point, is just a preview. It has to be processed by the sender engine in order to be actually saved to the database, and sent to the recipients.
2. The physical documents can then be saved to the database and sent to a number of recipients using the sender engine based on message sender configurations.
Part of this process is to define document templates. Defining document templates is described under Help > Message Template Keywords.
A number of document templates are provided out-of-the-box
under <calypso home>/client/resources/com/calypso/templates. They can be customized or you can create your own templates. Document templates
are registered in the “MESSAGE.Templates” domain. Templates contain free-form
text as well as template keywords to retrieve information from trades, messages
and transfers.
Sample Message Workflow
You will not be able to generate messages without a message workflow. The basic action of creating a message is represented by the transition NONE - NEW - <any status>.
The message workflow is configured by processing organization, product type, and message type.
Refer to the Calypso Messages documentation for complete
details.
Message Grouping
To generate grouped messages, the general process is the following:
| » | Define message grouping keys using the Message Grouping window. |
| » | Set message grouping keys on a message configuration using the Message Setup-Up window. |
| » | Run the MESSAGE_GROUPING scheduled task to generate the actual grouped messages. |
We currently support the generation of the following grouped messages:
| • | MT604 / MULTIPLE Precious Metal Transfer / Delivery Order, and MT605 / MULTIPLE Precious Metal Notice to Receiver. |
MT692 that allows canceling only one single Transaction of a Multiple Message (MT692 will be produced to cancel one transaction which is part of an initial GLOBAL/MULTIPLE Delivery Order Message MT604 or MT605).
| • | MT203 that allows grouping of MT202 / MT103 - MT205 that allows grouping of MT202 / MT103 |
Note that the grouping of MT202 only works for underlying MT202 XML templates.
| • | MT102 that allows grouping of MT103. |
| • | MT101 that allows grouping of individual MT101 - Refer to the Calypso Corporate Cash Management User Guide. |
Refer to Calypso Message Grouping documentation for complete details.
Reconciling incoming messages can be done manually through the task station (using the ACKED, NACKED, MATCH, MISMATCH actions, etc.), or using various processes depending on where the messages are coming from.
Refer to Calypso Message Matching documentation for information of out-of-the-box processes and complete details.
3. Transfer Generation
Expected transfers are generated by the transfer engine for any movement of cash or security attached to a trade provided the trades are associated with valid settlement and delivery instructions (SDIs).
Once a transfer is generated, it follows its own workflow for the actual settlement, cancellations, amendments, etc.
Netting
Transfers can be netted based on user-defined nettings keys (netting configuration) and netting criteria (netting method), or can be manually netted using the Pair Off Manager.
When transfers satisfy the specified criteria, they are netted according to the netting key until the user actually applies the EXECUTE action to the netted transfer. Subsequent transfers are netted into a new netted transfer until it is executed in turn. Note that for netting by trade id, you do not need to apply the EXECUTE action, the transfer is automatically executed when all underlying transfers are known.
The transfer engine processes automatic netted transfers in real-time.
Settlement
Transfers can be settled once they are verified. Transfers are verified when they are known (no reset or completed reset). Netted transfers are verified when all underlying transfers are known, and they have been executed.
Sample Transfer Workflow
You will not be able to generate transfers without a transfer workflow. The basic action of creating a transfer is represented by the transition NONE - NEW - <any status>. A standard transfer workflow is provided out-of-the-box. You should review the transfer workflow and modify as needed. The various actions of the standard workflow are described later in this document.
The transfer workflow is configured by processing organization, product type, and transfer type.
At any point of the transfer workflow, a payment message can be generated and the message workflow takes care of it.
Refer to Calypso Settlements documentation for
complete details.
4. Posting Generation
The accounting engine generates postings based on accounting rules. An accounting rule specifies for a given event which accounts will be debited and credited. A set of accounting rules is associated to a book through an accounting book. Part of this process is to define accounting books and accounts.
Refer to the Calypso Accounting documentation for
complete details.
5. CRE Generation
CREs (Compte Rendu d’Evenement) or Account Enrichment events allow Banks who do not want to have their debit/credit postings in their Back-Office system, send accounting events to external systems. These events do not hold details about what accounts are debited or credited.
CREs are generated by the CRE engine.
The CRE Sender engine actually sends the CREs using the CreSenderFormater interface, and updates their status. The CreSenderFormatter has to be implemented to produce the output of a CRE.
Refer to the Calypso
Developer’s Guide for details.
Note that you can also use the CRE_SENDER scheduled task, which sends the CREs using the CreSenderFormater interface, and updates their status. The CRE Sender engine is a real-time process, while the CRE_SENDER scheduled task is a batch process.
Refer to Calypso CRE documentation for complete
details.
6. Cash Management
The cash management capability is based on SETTLE accounts. A SETTLE account is associated with the agent that settles the trades of a processing organization.
Inventory positions are calculated by the Inventory engine based on transfers of cash and securities into SETTLE accounts. They can be monitored through the Inventory Position report which computes funding requirements over a user-defined period.
Account statement events are generated by the scheduled task ACCOUNT_STATEMENT based on inventory positions, and account statement configurations. The Message engine subscribes to account statements events and generates account statement messages based on statement message configurations.
Account interest trades (interest bearing trades) are generated by the ACCOUNT_INTEREST scheduled task based on inventory positions and interest bearing rules.
Account billing events are generated by the scheduled task ACCOUNT_BILLING based on inventory positions and account billing configurations. The Billing engine subscribes to account billing events to generate account management fees (billing trades) based on billing grids and fee billing rules.
Billing trades and interest bearing trades are generated on the funding book of the processing organization.
Inventory Position Flow
7. P&L Positions
The Liquidation Engine creates positions for products that are position-based.
The Liquidation Engine generates the Economic Position. The position for each security shows the amount of your holding and the associated realized and unrealized P&L. The positions are computed by default by book and product, but you can also compute positions based on any other aggregation criteria below book and product, as defined in the Liquidation configuration.
Trades are taken into account in positions based on the End of Day Valuation Date/Time and Time Zone of the books. Alternatively, you can define when the liquidation should occur in the LiquidationTime book attribute. Use the format HHMM. For example, if you set LiquidationTime to 2030, the Liquidation engine liquidates positions at 8:30 PM. If you do not set this attribute, then the liquidation occurs at the book EOD.
The Position Engine uses less data than the Liquidation Engine, thus improving performance when running position reports. It does not liquidate the positions.
The Position Engine aggregates positions by product, book, and settle date. You can also create positions using additional aggregation criteria, for example, by currency pair. Additionally, you can create a position history by setting-up settle position buckets to value positions at different times during the day.
Refer to Calypso Positions Management documentation for complete details.
8. Scheduled Tasks
Scheduled tasks are batch jobs for automating EOD processing: reports, trade activity, valuation, etc. They are executed by the Calypso Scheduler, and can also be executed on-the-fly.
The Calypso Scheduler is started in the background by your administrator.
The results of scheduled task executions are displayed in the Report panel of the Scheduled Task window, and also 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.
Refer to Calypso Scheduled Tasks documentation for complete details.
How are we doing?