Trade Bundle Workflow
There is a workflow that is specific for Trade Bundles and the back office specifics of handling them. The Trade Bundle Workflow gives the ability to generate one unique message when certain changes are made to the trade bundle. It also allows for the generation of specific exceptions based on Underlying Trade status or Trade Bundle status.
| » | There is an AMEND constraint related to trades in a bundle that are added, amended or canceled. The applied action depends on the environment property APPLY_TRADE_ACTION_TO_BUNDLE. |
| – | If the property is false or not set (default), we apply the action AMEND on the bundle when a trade is added or removed to the bundle. |
| – | If the property is set to true, we apply NEW when we add a trade to a bundle, and REMOVE when we remove a trade from a bundle. |
| » | When the Trade Bundle workflow is implemented after having already entered a bundle, the bundle status is set to NONE. In order to modify this bundle, the transition of NONE-AMEND-PENDING is needed. |
Ⓘ [NOTE: Only one Trade Bundle workflow can be defined to deal with ALL trade bundles]
1. Trade Bundle Workflow Creation
Step 1 - Activate the Trade Bundle workflow by adding TradeBundle in the WorkflowType domain. (From the Calypso Navigator, navigate to Configuration > System > Domain Values.)
Step 2 - Configure the Trade Bundle workflow by opening the Workflow Configuration window to create a new workflow. (From the Calypso Navigator, navigate to Configuration > Workflow > Workflow).
Select the Event Class TradeBundle.
Step 3 - Choose Domain > Entity > Add Status, and add the status: codes NONE, PENDING, CANCELED and VERIFIED.
Then, choose Domain > Entity > Add Action, and add the actions AMEND, CANCEL and EXECUTE.
Step 4 - The Trade Bundle rule GenerateBundleStatement is required to trigger a message to the Message Engine. To add this rule, choose Domain > Entity > Add Rule.
Then add this rule to the PENDING EXECUTE VERIFIED transition.
Ⓘ [NOTE: A trade bundle event is produced only if a trade bundle is defined with the "One Confirmation Message" checkbox selected and if all trades are in the same status.
In order to avoid the generation of unwanted bundle statements when all trades in a bundle are in the same status, there is a domain called "TradeStatusForBundleStatement". This domain allows you to designate a trade status required for statement generation. From the Calypso Navigator, navigate to Configuration > System > Domain Values to create this domain and add the desired status.
In the workflow rule GenerateBundleStatement, if the parameter 'UnderlierTradesSameStatus' is specified i.e, set to true or empty, it generates the BundleStatement if all trades have the same status (Default is true);
When set to False, the system generates the BundleStatement event without checking all the trades' same status.
1.1 KickOff / CutOff
There is an unlimited number of trades that could be saved to a bundle. A user may decide to sequentially save several trades. In this case, the GenerateBundleStatement rule could trigger an event to the Message Engine for each of the saved trades. To prevent this from happening, the KickOff/CutOff configuration can be implemented on the Trade Bundle workflow.
| » | Check "Use KickOff/Cut Off" and add the CheckKickOff workflow rule. |
To configure the KickOff/CutOff, choose Domains > KickOffCutOff Config from the Workflow Configuration window.
Ⓘ [NOTE: If one trade is canceled, the PSEventBundleStatement contains a sub-action, Cancel. This logic allows the generation of Amend or Cancel/New confirmations when one of the trades is canceled or removed, or added to the bundle. You need to configure the message workflow to make use of the CANCELNEW action]
Make sure that the Message engine subscribes to PSEventBundleStatement in the Event Manager of Web Admin.
1.2 Other Trade Amendments
In order to handle trade amendments other than cancellation or adding or removing a trade bundle, the Save Trades function accommodates an AMEND action on the trade bundle when certain conditions are met:
| • | The trade belongs to a bundle |
| • | A trade is canceled and it belonged to a bundle or a trade bundle that is attached to a trade has been amended with another bundle |
| • | The trade bundle did not change but the amended trade is eligible for a confirmation regeneration (If the trade fields amended do not belong to the fields listed in the domain "TradeFieldsNotAmendment") |
There is also a domain called "ActionNotAmendBundle" that when used, does not apply the AMEND action even if the above conditions are met. Generally, most people do not want to regenerate a confirmation on a final transition like Exercise, Expire or Terminate.
2. Bundle Task Station
You only have the ability to see one task per bundle in the Task Station. Trade Bundle tasks are created with a default book attached to the Trade Bundle. By default, this trade bundle book is set automatically as the book of the fist trade linked into the Bundle. The default book can be overwritten from the Trade Bundle window.
From the Task Station you are able to:
| • | Open a Trade Bundle window |
| • | Open the BO Bundle Browser |
| • | Open a message report to see messages triggered by the TradeBundle Event type for the selected Bundle Id. |
3. Transfer Workflow
You can use the transfer rule CheckPendingTradeEventByBundle to make sure that all trade events of a given trade bundle have been consumed by the Transfer engine.
How are we doing?