Update Cost Object After Changing Security Data Processing Notes
When a trade is booked in Accounting, some key security master file (SMF) attributes are stored on the cost object. These can be viewed under the Cost > Summary tab in Position Viewer. When subsequent trades are booked for the same security, those attributes are inherited by the new cost lots rather than being retrieved from the SMF. If you book a trade, update the SMF, and then book another trade, the second trade will still act the same as the first trade.
This can cause testing difficulties as the results may not be reflective of the functionality you are trying to test. If you change Variation Margin (4533) on a future contract from No
to Yes
between open trades, the subsequent trade will still process as No
in Accounting, but it may appear as Yes
on some reports. There are also processes that always rely on the SMF data directly, which can produce results that are difficult to reconcile because they are using different data.
There are a number of options for correcting this situation when it arises, each with its own pros and cons. We recommend starting with # 1 because it is the cleanest, but if you are amenable to # 6, that is the most certain way to resolve the issue in all cases with minimum risk.
Use Modify Object Level Data - Existing Position
Pros: this a core maintenance event designed specifically to update SMF data stored on the cost object
Cons: not all fields are supported
Supported fields: Investment Type (11), Quantity Type (12), Maturity Date (38), Price Multiplier (18), Quantity Scale (19), First Coupon Date (473), Last Coupon Date (474), Underlying Coupon Rate (4349), Variation Margin (4533), Var Margin Rule (4350), and Coupon Type Code (97)
Use Update Clearing Broker
Pros: this is a core maintenance event designed specifically to change the Clearing Broker (1237) stored on the cost object
Cons: only one field supported
Ensure this is fully tested in a lower environment to prevent issues with variation margin (VM) and close trade processing
Cancel open trade, change SMF attributes, and rebook
Pros: canceling and rebooking is a familiar workflow and users typically have access to do this themselves
Cons: does not work in 100% of cases; sometimes the cost object continues to show the original value
Change SMF attributes, book a dummy close, cancel the close, cancel open trade, and rebook the open (booking the close updates the cost object in some cases)
Pros: this may work when # 1 does not and still uses the same processes
Cons: you have to enter a dummy close and it requires more cancels
This is an example based on VMÂ
Open future position with VM = No on SMF ---> cost object shows VM = N
Change VM = Yes on SMF ---> cost object still shows VM = N
Book dummy full close for position ---> cost object now shows VM updated = Y
Cancel dummy close ---> cost object still shows VM = Y
Cancel open ---> cost object still shows VM = Y
Same as # 2, except use Delete A Position after canceling the open
Pros: works in all cases because the cost object for the given entity/security combination is wiped out and then reestablished
Cons: most users do not have access to this process and Delete A Position can cause issues with PACE data if STAR to PACE is not run between canceling the open and deleting the position because it only effects the STAR position
This workflow should only be used if you are familiar with Delete A Position or after adequate testing in a lower environment
Cancel open trade, set up a new SMF with the correct details, and rebook with new SMF
Pros: works in all cases because a new cost object record is established for the new security
Cons: creating a new security with the same identifiers requires updating the original security to use different identifiers