MX 3.1 Pre-Post Trade Workflows

MX 3.
1 Pre-Post Trade
workflows
Murugesan Prabhakaran
15th Aug 2013
ITMP T-4-3-1-24A Template Version 1.2 1

Agenda
• Key Differences between 2.11 & 3.1
• Pre Trade workflow
• Post Trade workflow

Key difference between 2.11 & 3.1
• Trade Repository
 Trades Hierarchy & Design
 Events
 Versioning
• Exception based management

• GUI Integration framework

Key difference between 2.11 & 3.1 – Trade Repository
Trade Repository – Trade Hierarchy
• Financial Contract Component:
 Basic building block (Simple Trades).
 Elementary level of information in a trade for P&L and sensitivity calculation.
 Can not live independently from processing point of view
• Financial Contract:
 A set of components dealt with one counterpart and seen as single object during processing.
 Linear combination of financial contract components
• Financial Contract Package:
 A set of financial contracts
• Financial Contract Event:
 An event applied on one or several component and triggers contract versioning.

Trade Repository – Trade Design



• FX Swap with one counterpart
 1 FC with 2 FCC
• FX Swap(FC) = Spot ( 1st FCC) + Forward (2nd FCC)

• FX Swap with 2 counterpart
 1 Package with 2FC
 Each FC includes 1 FCC

Trade Repository – Trade Events
• Business event on Financial Contract or Package
• Event Characteristics
 Impact on the Financial Contract
 Generates new financial Contracts
 Generates cash flow

Trade Events
• Graphical Representation
 Tree structure summarizes the successive events and indicating respective reference numbers

Versioning
• Purpose
 Easier reconciliation and confirmation with counterpart after trade amendment
• Contract number is fixed
• Number indicating the version number

Versioning
• Mechanism
 Every event publishes its impact in the contract workflow
• Impact on existing & new transactions
 A copy of initial trade is generated
• Impact occur on the copy
• Generated cash flow are attached to the copy
• Event on Trade
Example: Counterpart allocation

Versioning
• Cancel of an event
 Copy is cancelled and initial deal is versioned
 Cancel of any new trade generated by an event
 Cancelled trades are published in contract workflow

Versioning
• Events and relation to versioning
 Event that does not generate a new deal – Fixing
 Event that generates new deal

Key difference between 2.11 & 3.1- Exception based management

Key difference between 2.11 & 3.1- OSP

Key difference between 2.11 & 3.1 – GUI Integration framework
 Third party software displayed in murex window like Excel

Pre Trade Workflow
• Overview
• Pre-Trade Cycle & Organization
• Pre-Trade or Post-Trade
• Pre-Trade Sequences
• Scripting Language
• Type of Tasks
• Tasks & Rules Assignments

Pre Trade Workflow - Overview
 Automation logic for achieving higher STP rate

Pre Trade Workflow – Pre-Trade Cycle & Organization
• Synchronous mode
• Done in Memory Mode
• Access to pricing and real time market data

Pre Trade Workflow – Pre-Trade Cycle & Organization
• Both FO & BO users can call a Booking, Pricing and Closing sequences
• FO users can call Booking sequence attached to Processing center or specific Booking sequence

Pre Trade Workflow – Pre-Trade or Post-Trade
• Most of the automation logic should be covered with in Pre-Trade rules rather than with in Post-Trade
workflows. This will help in reaching higher STP rate.
• Pre-Trade rules are considered as an initiation phase for Post-Trade workflows
• Financial checks can easily be done in Pre-Trade workflows and the result check can be stored in a UDF
and reused in Post-Trade workflows

Pre Trade Workflow – Pre-Trade Sequences
• Calculation Chain ( Pricing & Closing Sequences)
 Pricing Sequence
• Set of rules automatically executed in order to customize the pricing of each time
 User enters a field in deal ticket, pricing, e-TradePad or FDI
 Trade is generated by MOP
 Trade is imported from an external system
• Represented in a flow sheet connecting several tasks
 Typical flow sheet contains completion task to fill-in inputs, pricing task
• Typical tasks:
 Completion Rules: automatic fill-in one or several fields in deal ticket based on condition
 Pricing tasks: Trigger actual pricing models
 Routing tasks: Route to another branch of flow sheet
• Closing Sequence
 Set of rules automatically executed just after pricing sequence
• Executed only once
• Not supposed to modify pricing input
 Represented in a flow sheet connecting several tasks
• Typical flow sheet contains several completion tasks with routing tasks
 Typical tasks:
• Completion rules: Typology, portfolio assignments, Tradability status
• Routing tasks: Router to another branch of flow sheet

• Booking Sequence
 Set of rules automatically executed in order to customize the trade insertion each time
• User hits the save button
• A trade is generated by MOP
• A trade is imported from an external system
 Rules are applied in a sequence of tasks which are executed before trade is saved physically in to system
 Typical Rules
• Completion Rules: Broker allocation and fees calculation, SSI allocation
• Routing rules: Route to specific branch of flow sheet
• Compliance Rules: Sanity checks using trade characteristics. Warning or error messages
• Mirroring & Hedging rules: BTB & generation of hedges

• Calculation chain or Booking sequence
 Calculation chain
• Rule will be executed at each computation in calculation chain
• Calculation chain has to be used if an interaction with the end user before the trade insertion is required
 Booking Sequence
• Booking sequence should be used as the rule will be applied only once
• Sanity Checks (Compliance) have to be performed in Booking sequence
 Users will be disturbed by warnings and error messages during calculation chain
 Checks on computed data such as NPV, market value and prices sensitivities should be done
• Mirroring rules should be done in booking sequence

• Sequence construction Steps

 Pre-trade sequences are executed in following order
• Tasks Assignment selects the flow sheet
• Flow sheet defines the succession of tasks to be executed
• Rules Assignment selects the rule to be applied for each task
• Selected rules are executed in the order specified in the flow sheet

Pre Trade Workflow – Scripting Language
• MSL ( Murex Scripting Language) being used to build pre-trade rules

• Generic Functions
 Integer legGetNumberOfComponents(Pointer)
• Returns number of FCC within a FC or Package
• Parameters: FC or Package Pointer
 Pointer legGetComponentAt(Pointer, i)
• Returns a FCC pointer
• Parameters:
 A FC or Package pointer
 FCC number with in FC or Package
 Pointer legGetMainComponent(Pointer)
• Returns a FCC pointer
• Parameters: A FC or Package pointer
 At Package/FC level, loop is required as number and the nature of the legs is not known in advance

Pre Trade Workflow – Scripting Language
• Generic Functions
 At Single Contract level, it is not mandatory to use a loop
 List of functions and key words can be find using:

• Press F9 to access Key words list
• Press Shift+F9 to access functions list

Contract Sequence
 Warning to popup when the user saves IRS trade when nominal amount is greater that 100 000 000
 Example of compliance rule

Event Sequence
 The sequence is triggered when a market operation is performed ( Cancel, C&R, EXR,EXT,ET.. Etc)
 Completion and/or compliance rules can be applied on the initial deal, the event and generated/cancelled deals
 Example:
• Field portfolio of the initial deal has to be copied in UDF INIT_PTF of the reissued deal while performing C&R
• Below completion rule can be used

Deliverable Sequence
 The sequence is triggered whenever a deliverable is generated if deliverable module is activated
 Generation of deliverables occurs when:
• Deliverable value date is with in the deliverable window period
• Contracts are inserted with schedules including known flows
• Events are performed. Example: Fixing
 Deliverables would enter the pre-trade sequence after Settlement / Deliverable template has been applied
 Deliverable sequence can be used for pre-netting/MM Rollovers
 Only Booking sequence is triggered every time deliverables are generated
 Events may impact deliverable directly or indirectly
 Events on deliverables
• Deliverables can be cancelled, C&R, Split  Not advisable
• Netted

Deliverable Sequence
 Example:
• Completion rule to delete flows generated from SCF, Null cash flows, FX cash having typology starts FX_

Pre Trade Workflow – Debugging
• Activate/deactivate the debugger by selecting the menu Help/Monitor  Double click on Formula
Debugger or using the option /FRMLOG:filename to debug to a file. Add optionally
/FRMLOGFILTER:namespace1;namespace2.. To filter on subset name spaces
• A log file can also defined in Mx launcher or Trade Repository

 This is useful for trade interfaces

Pre Trade Workflow – Type of Tasks

Pre Trade Workflow – Tasks & Rules Assignments

Post Trade Workflow
• Post Trade Main Notions
• Introduction
• Workflows
• Amendment Agent
• Status
• One-Stop Processing
• Post-Trade and Organization
• Post-Trade workflows triggering
• Post-Trade workflows configuration
• Interaction between Workflows

Post Trade Main Notions
Introduction
 Post-Trade is a set of workflow automatically initiated whenever an event is performed on business
object (contract, package, deliverables, static data.. Etc)
 It groups all actions performed in an asynchronous way in order to manage statuses, perform
validations, generate confirmation and communicate to external systems

Post Trade Main Notions
Workflows
 A workflow is a set of auto & manual tasks connected together representing a given business process
 Each business object has its dedicated workflow
 Contract
 Event
 Deliverable
 Exchange
 Package
 SSI
 Workflow optimize the entire processing by providing STP mechanism based on:
 Automatic tasks for automatic jobs
 Manual tasks to handle exception

Post Trade Main Notions – Amendment Agent
 Amendment is responsible for connection between MX and MxML Exchange services
 Entry Point of a workflow working as routing matrix. Any business object represented in MX is exported
in to MxML Exchange where it follows a designated workflow.
 Example for contract workflow

Post Trade Main Notions - Status
 To identify current validation or processing state of an object
 Definition of object rights depends on object validation status
 Two types of statuses:

 Validation Status ( STP_VALIDATION_LEVEL) of the object
 Mandatory
 Used to set access rights on the objects ( STP rights)
 Additional Status
 Optional
 Not linked to access rights
 Only used inside the workflow

Post Trade Main Notions – One-Stop-Processing
 STP mechanism where every task is automatic with manual management of exception
 Centralized and generic tool allows end-users to process (validate/reject) business objects waiting in
manual tasks
 Access to manual tasks are allocated to groups of end-users in charge of validating contracts, processing
payments and generating confirmations

Post Trade Main Notions – One-Stop-Processing
 Ability to define specific layout with customized views and filters can be used depends on the business
object users need to validate
 Example for document/conformation processing
 Example of payment processing

Post Trade & Organization – Processing Center
 Responsible of managing the processing of set of legal entities
 Must be linked to a Processing Template ( a set of workflows)

Post Trade & Organization – Front Office Desk
 Front office Desk & Processing Center
 Every FO Desk must be attached to a processing centre. This will use underlying processing template
 An FO Desk group uses the Processing template to manage it own workflows

Post-Trade Workflows Triggering
• Workflows are triggered by creation, amendment or any other event on their corresponding BO
 Insertion of contract triggers contract workflow and may also impact the deliverable workflow

• One event in MX may trigger many workflows
 Creating new package triggers the contract & package workflows

• Each Business Object type has its dedicated workflow

• MxML Format
 Business Objects are represented in MxML format inside the workflow
 Murex proprietary XML format used to publish and to transfer the data between MX.3 and Post trade workflows
 MxML file depends on object and event represented
 <events> node is added whenever MxML file is sent to exchange workflow

Post-Trade Workflows Configurations - Status
• Status
 One building block of the workflows
• Status assignment
 Field Overwrite functionality at node level
• Workflows are action driven, not status driven

• Status inherited at node level can be:

 Static : Same status for all objects going through this node
 Dynamic : A formula returns the correct status depends on object characteristics

• Specific configuration for Contract

 Trade acceptance can be based on Contract status when PL control pre-selection mode is set to Status
 Only contracts in status “ candidate for official P&L” are selected will be part of official P&L of the bank for the closing
entities.
• Specific configuration for Settlements

 Settlement Validation Status
• Cancel Strategy
• Accounting configurations
• Nostro balance configurations
• Specific rights

• Specific configuration for SI Validation Status

 Is the SI in such a status eligible or not?

Post-Trade Workflows Configurations – STP Rights
• Proper access rights by status (STP Rights) must be granted to each group of users in SUPERVISOR
session.
• STP Rights
Each group has specific access /modification rights to each class of object and event depends on status
 Deal entry – Deal Modification
 Event entry - Event Modification
 SI entry – SI Modification

Post-Trade Workflows Configurations – STP Rights

Post-Trade Workflows Configurations – Amendment Agent
• Possibility to identify the underlying event and handle the flow
• MxML Exchange Spaces – Specific to business Object being handled

Object Space Name Specific Fields
Contract STPFC_ENTRY_TABLE FC_ID,FC_ORIGIN_ID
Document STPFC_ENTRY_TABLE DOC_ID, DOC_PARENT_ID
Event STPEVT_ENTRY_TABLE EVENT_ID
Deliverable STPDLV_ENTRY_TABLE / DLV_ID

STPSTL_ENTRY_SPACE

Post-Trade Workflows Configurations – Amendment Agent
• Spaces Main Fields – Common to all Spaces

 REFERENCE ID
 STATUS_TAKEN
 XMLFLOW_STATUS
 FC_ID
 FC_PACKAGE_ID
 FC_POERFOLIO
 STP_LAST_VALIDATOR
 STP_STATUS1,2,3,4
 STP_STATUS_VALIDATION_LEVEL
• Amendment agent service should be up and running to publish the object in to specific workflow

Post-Trade Workflows Configurations – OSP Rights
• Access rights are granted by manual task

Post-Trade Workflows Configurations – Workflow tasks
• Common tasks can be used
Task Description Auto /

Manual
Router Routing objects towards different paths A
Timeout Holding objects during a user defined A

Trigger number of seconds
Flow Trigger Updating an object located in another A Check Cycle Checking a set of criteria and routes to A
workflow with possibility to push it to a Check Exception if needed
specific task
Date Trigger Holding objects until a certain date & A Check Manual Validation from Check Cycle M
time Exception
Document Sending xml representation of the A

Sender object to the exchange workflow
Authorisation Manual Validation
Queue M
Answer Router Managing the potential answer from the A
exchange workflow
Answer Returning the answer to the underlying A

Sender workflow

Post-Trade Workflows Configurations – Workflow Tasks
• Manual Validation Task
 Possible actions for example we have it Phase 1- Contract Validation in Python
• Accept
• Route it to exception
• Validation Cycle
 Check missing SI
 Check CI
 Check back dated trade
 Check MISC counterpart

Post-Trade Workflows Configurations – Workflow Example
• Validation Cycle
 Exception Found  Entry sent TO_VALIDATE
 If Exception manually accepted contract will be send back to validation cycle task and check other exception
defined
 No More exception found, entry will be sent to VALIDATED

• Timeout Trigger
 Objects remains specified in the status
• Date Trigger
 Deliverables can be further processed only X dates before the release date
 Deliverables messages can be sent only X minutes before the cut-off time.
• Flow Trigger
 Deliverables are routed in to the waiting queue in the workflow
 Deliverables will be released from waiting queue from initial phase to validation phase once the contract is confirmed
and status is CON/CFM
• Doc Sender
 Contract MxML document will be sent to document workflow in order to produce contract confirmation
 Amendment agent of the workflow is impacted

• Current Python Contract workflow
 Workflow will need to enhance for main instance to replicate the process we have it in 2.11

Interaction between Workflows
• Real and wide communication between workflows
• An event occurring in one specific workflow can have an impact on other workflows
 Validation of a contract : Contract workflow triggers the exchange workflow in order to create confirmation once
contract has reached confirmation initiation phase
 Amendment of contract : Contract is re inserted in to contract workflow and the exchanges belongs to this
contract are re-injected in exchange workflow ( Automatic and non customizable)
 Processing of payments : Possibility to force the payments to wait at a specific phase in settlement workflow and
automatically release them from the contract workflow once contract has reached confirmed status using Mx
Trigger task

Interaction between Workflows

Questions ?

Thank You!

MX 3.1 Pre-Post Trade Workflows

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

MX 3.1 Pre-Post Trade Workflows

Uploaded by

Copyright:

Available Formats

MX 3.

15th Aug 2013

ITMP T-4-3-1-24A Template Version 1.2 1

• Key Differences between 2.11 & 3.1

• Pre Trade workflow

• Post Trade workflow

ITMP T-4-3-1-24A Template Version 1.2 2

• Exception based management

ITMP T-4-3-1-24A Template Version 1.2 3

ITMP T-4-3-1-24A Template Version 1.2 4

ITMP T-4-3-1-24A Template Version 1.2 5

ITMP T-4-3-1-24A Template Version 1.2 6

ITMP T-4-3-1-24A Template Version 1.2 7

ITMP T-4-3-1-24A Template Version 1.2 8

ITMP T-4-3-1-24A Template Version 1.2 9

ITMP T-4-3-1-24A Template Version 1.2 10

ITMP T-4-3-1-24A Template Version 1.2 11

ITMP T-4-3-1-24A Template Version 1.2 12

ITMP T-4-3-1-24A Template Version 1.2 13

ITMP T-4-3-1-24A Template Version 1.2 14

 Event that generates new deal

ITMP T-4-3-1-24A Template Version 1.2 15

ITMP T-4-3-1-24A Template Version 1.2 16

ITMP T-4-3-1-24A Template Version 1.2 17

ITMP T-4-3-1-24A Template Version 1.2 18

• Pre-Trade Cycle & Organization

• Tasks & Rules Assignments

ITMP T-4-3-1-24A Template Version 1.2 19

 Automation logic for achieving higher STP rate

ITMP T-4-3-1-24A Template Version 1.2 20

ITMP T-4-3-1-24A Template Version 1.2 21

ITMP T-4-3-1-24A Template Version 1.2 22

ITMP T-4-3-1-24A Template Version 1.2 23

ITMP T-4-3-1-24A Template Version 1.2 24

ITMP T-4-3-1-24A Template Version 1.2 25

ITMP T-4-3-1-24A Template Version 1.2 26

• Sequence construction Steps

ITMP T-4-3-1-24A Template Version 1.2 27

• MSL ( Murex Scripting Language) being used to build pre-trade rules

ITMP T-4-3-1-24A Template Version 1.2 28

 List of functions and key words can be find using:

• Press Shift+F9 to access functions list

ITMP T-4-3-1-24A Template Version 1.2 29

ITMP T-4-3-1-24A Template Version 1.2 30

ITMP T-4-3-1-24A Template Version 1.2 31

ITMP T-4-3-1-24A Template Version 1.2 32

ITMP T-4-3-1-24A Template Version 1.2 33

• A log file can also defined in Mx launcher or Trade Repository

ITMP T-4-3-1-24A Template Version 1.2 34

ITMP T-4-3-1-24A Template Version 1.2 35

ITMP T-4-3-1-24A Template Version 1.2 36

• Post Trade Main Notions

• Post-Trade and Organization

• Post-Trade workflows triggering

• Post-Trade workflows configuration

• Interaction between Workflows

ITMP T-4-3-1-24A Template Version 1.2 37

ITMP T-4-3-1-24A Template Version 1.2 38

ITMP T-4-3-1-24A Template Version 1.2 39

ITMP T-4-3-1-24A Template Version 1.2 40

 Two types of statuses:

ITMP T-4-3-1-24A Template Version 1.2 41

ITMP T-4-3-1-24A Template Version 1.2 42