Most organizations rely on securities from Bloomberg, loaded using SimCorp’s solution for Bloomberg Data Licenses. In this piece, we are going to explore some methods that can be implemented to improve non-standard setup solutions and help ensure the process is done seamlessly.
The normal setup will have separate requests laid out for different instrument types. This is generally a problem so to speak, but it is simpler and more convenient to have 1 request definition to send new requests for an asset back, security, and an option all at the same time. With a bit of excel exercise, this is quick and easy to implement.
First, you need to make sure that all field mnemonics across the DFS’s are assigned a unique number. You mustn’t have 2 assigned to the same number. Once you have all unique numbers assigned, you set this up in the external data ‘column’ field of the DFS.
Once you have the fields aligned you use the security type already set up in the DFS to determine what instrument type the record is in. For example, if it is the equity you want it to be loaded in the Equity DFS, and removed from all other DFS’s. One way to simplify this could be to have a translation for each DFS on a temporary field that sets all equity security types to 1, and the rest to 0; or you can use a formula to lookup security types.
Once the instrument logic has been set up, you add a reformat function to all DFS’s called ‘Only keep records where..”. This needs to be an end-function. Par1 is the temporary field or the security type and par2 is either 0 (if you have used the translation described above), the security types, or the instrument type of the DFS.
Lastly, you create one Bloomberg Request definition where all DFS’s are added together, including the ones for parties/issuers, and include loading all fields.
When you send the request to Bloomberg, you cannot define a field other than the order of the fields in which they appear. So, if you request field orders 4, 10, and 12, you will get back 4, 5, and 6 (1-3 are reserved by Bloomberg). The communication server will ensure the records are re-ordered so they match the DFS. However, if the record is on the message queue, it is difficult to research breaks without the raw original data. We recommend setting up the DFS’s so no field order is missed (the ‘column’ in the external data tab on the DFS). If you have a skip in numbering, add the mnemonic BLANK_FIELD where there are records skipped in the DFS. That way, you can always load the raw response file if a break requires more research than the message queue can offer.
The last tip is around the temporary fields in the DFS. Especially for Bonds, the DFS runs out very quickly if it has not already done so. You can of course go through all formulas and reformat functions to check what is used. A DEX on formulas can help to identify where a temporary field is used by searching for a temporary field. Some might not even be used. For other fields, consider the use of a security-free code as a better place to store the data. Not only can it add value to have this on the SMF, but it is an easy way to free up temporary fields. It is ideal for more temporary fields to become available, but until that happens, it is possible by doing a little cleanup.
If there are any further questions or comments you may have in regards to this topic don’t hesitate to let us know.