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
Add Comment