OVERVIEW
The Recon – SOD Position Values report is a tool for verifying record accuracy. This is accomplished through the automated comparison of Spark records to the records kept by the Prime Broker. When a difference between Spark’s records and the broker’s records is identified, the discrepancy is marked as critical within the report (See “Filtering”). By marking these discrepancies, Spark users are provided with an alert system that gives insight to records which may be inaccurate. The SOD Position Values report also provides auxiliary information which can be used to locate and correct the underlying problem which has created the record inconsistency.
REPORT AND VIEWS
Within the report, there are a series of tabs, or “views”, which provide report flexibility to the user. The “View” titles and descriptions are as follows:
Position Quantity:
This view serves as a base level reconciliation report. This should be the first report that a user looks to for information on a record inconsistency, as an incorrectly recorded quantity can cause additional breaks on all other reconciliation report views. Corrections to the Position Quantity view will also correct issues that are present in the following reconciliation views.
Trade Match Breaks:
The Trade Match Breaks view is a variable use view which can be adjusted depending on the type of break being researched by using the “Test Value” filter (See Filtering). This view shows breaks where the security information from both Spark and the Broker match, but the data they hold does not. This view is a subset of the others as it does not show breaks caused by “identifier differences” (Identifier differences are covered in Problem 3 in section 4).
Price Breaks:
This view locates differences in the recorded close price between Spark and the Broker. This view should be the next stop in correcting a PnL discrepancy, should no solution be found on the Position Quantity view.
Market Value Breaks:
This functions in the same manner as the Price Breaks view, however this view focuses on differences in market values as opposed to close prices.
Position Unrealized:
Searches for value mismatches between Spark’s unrealized positions and those of the prime broker / brokers. This filter can be customized by time period depending on the time period used by the broker.
COLUMNS AND FILTERS
Below is a layout key columns in the report, and their various filters:
Severity:
Critical: This filter will show all items where the Spark Value and the Source Value do not match. These items require reconciliation.Informational: This filter shows items where the Spark Value and the Source Value match. These items do not require reconciliation.
TestValue:
These filters determine the type of value being reconciled.
EX: Filter of quantity means that the SparkValue and Source Value columns are showing the share quantity held in Spark and by the broker respectively.
Quantity: This will show the quantity of shares held by the broker and Spark.
As-Of Quantity: Shows the quantity as of a designated date (Note: Item is in production stage as of now).
Position Unrealized: Choosing this filter allows the recon to function for position unrealized. This column will be customized on a client to client basis to match the broker statements provided.
Market Value: This will show the market value recorded by the broker and Spark.
Close Price: This will show the close prices recorded by the broker and Spark.
StandardSecurityDescription:
This column is mapped to pull the Spark description for a security first. If no description is provided in Spark, this column will then pull the description provided by the broker.
StandardSymbol:
This column is mapped to pull the Spark symbol for a security first. If no symbol is provided in Spark, this column will then pull the symbol provided by the broker.
StandardAbsValue:
This column is mapped to pull the Spark value for a security first. If no value is provided in Spark, this column will then pull the value provided by the broker. This column is formatted as an absolute value, so all results will be positive. Breaks due to identifier mismatching can be quickly identified by ordering the values in this column sequentially.
ReconKey:
This column is used to match broker records to Spark records in order to compare values. This column is a concatenation of the following. The below list is inaccurat order:
– Prime Broker
– Test Value Designation
– Spark Symbol
– Spark Account
– Spark Side (Long vs. Short)
– Broker Symbol
– Broker Account
– Broker Side (Long vs. Short)
This concatenation can be quickly used to located breaks due to matching (See Problem 3 in section 4)
COMMON PROBLEMS WITH SOLUTIONS
PROBLEM 1) A BREAK OCCURS IN THE RECON REPORT DUE TO SPARK HOLDING A POSITION THAT IS NOT REFLECTED BY THE BROKER. POSSIBLE CAUSES:
1. Shares, of the security showing a break, have been sold without entering the transaction in Spark. In this case, the broker will receive the instructions to sell the shares and update their records. Spark will continue to hold its original position, causing a break on the recon report until the correction is made.
Solution: Update Spark by processing the appropriate trade ticket in Spark. When updating Spark in this manner (i.e. processing a trade for recordkeeping which has already been booked by the broker) be sure to set the ticket to a manual transaction and set the ticket to NOT export. Make sure that all tags (under the strategy dropdown) are correct. Having incorrect tags can cause a transaction to be recognized by Spark without amending the position Spark is showing for the security. If your position is incorrect, and all proper trades have been entered into Spark, the problem is likely that the tags for one of the Spark transactions are incorrect (See Problem 4).
2. Shares have been purchased recently for the security showing a break. In this case, the break will be due to a lag in brokers updating their statement.
Solution: This is normally a self-correcting break and will clear once the broker updates their records.
PROBLEM 2) A BREAK OCCURS IN THE RECON REPORT DUE TO THE BROKER HOLDING A POSITION THAT IS NOT REFLECTED BY IN SPARK. POSSIBLE CAUSES:
1. Shares, of the security showing a break, have been purchased without entering the transaction in Spark. In this case, the broker will receive the instructions to purchase additional shares and update their records. Spark will continue to hold its original position, causing a break on the recon report until the correction is made.
Solution: Update Spark by processing the appropriate trade ticket in Spark. When updating Spark in this manner (i.e. processing a trade for recordkeeping which has already been booked by the broker) be sure to set the ticket to a manual transaction as well as set the ticket to NOT export. Make sure that all tags (under the strategy dropdown) are correct. Having incorrect tags can cause a transaction to be recognized by Spark without amending the position Spark is showing for the security. If your position is incorrect, and all proper trades have been entered into Spark, the problem is likely that the tags for one of the Spark transactions are incorrect (See Problem 4).
2. The purchase of shares was properly entered in Spark, which immediately alters the position shown. The broker will continue to show the original position due to the broker statement being subject to a lag in updating.
Solution: This is a self-correcting break that will be cleared from the recon once the broker updates their statements to reflect the latest transaction.
PROBLEM 3) THE BROKER AND SPARK VALUES MATCH, HOWEVER THE RECON IS SHOWING THE SECURITY AS HAVING TWO BREAKS; ONE IN WHICH ONLY THE BROKER HOLDS ANY POSITION, AND THE OTHER WHERE ONLY SPARK HOLDS A POSITION. FOR THIS TYPE OF BREAK IT IS EASY TO SEE THAT THE SECURITY TIES IN ACTUALITY, BUT PRESENTS AS A BREAK IN THE RECON REPORT DUE TO INCONSISTENCIES IN BROKER STATEMENTS. WHILE THESE BREAKS ARE SUPERFICIAL IN NATURE, THEY IMPEDE THE ACCURACY OF SPARK’S OTHER REPORTS, SO IT IS IMPORTANT THAT THESE BREAKS ARE CORRECTED PROPERLY.
Possible Causes:
1. The symbol entered used by the broker differs from the symbol used by Spark. This difference in symbols is sometimes due to an actual alteration of the symbol by a brokers processing system when generating a statement, however, there are other causes. In some cases, a broker may not have a symbol available internally. When this happens, they will usually substitute an alternative identifier. These alternate identifiers include the cusip, sedol, isin, or an internal ID that is created by the broker. When a broker substitutes one of these identifier types for the symbol, the recon mapping becomes negated for the symbol the broker replaces. In the screen shot above, it can be seen that for security description “The Score Inc – A” the broker is using the sedol B89KHR2 while Spark is using the symbol SCR CN. To account for this, Spark uses a tool called “xrefSecurity”.
Solution: In order to correct these breaks, use the xrefSecurity as outlined below:
XrefSecurity is a tool that will match a symbol from Spark to a different identifier from a specific data source. In the case of the above reconciliation break, that source is the broker statement for Jefferies. In the above scenario, it is clear due to the value and the description that these two lines should be consolidated into one, thereby reconciling the break. To do this, open the entity “XrefSecurity” in the maintenance window.
Scroll down and select Security: Setup/Edit Cross-Reference Mapping for Securities.
– For “Active”, leave this as True. If you change this to false, the information in this XrefSecurity will be ignored by the SOD Recon.
– Select EntityId and a dropdown arrow will appear. Type the first few letters of the Spark symbol then click the dropdown arrow and select the correct security.
– Select “XrefDefinitionId” and a dropdown arrow will appear. From the available options, choose the appropriate data source where the source symbol is being generated.
– In XrefValue, enter the source symbol, then press save.
Once the XrefSecurity has been saved, the two breaks shown on the recon will consolidate into one. At this point the Spark value and the Source value will match, clearing the break on the recon.
PROBLEM 4) THE POSITION SHOWN IN SPARK IS INCORRECT, HOWEVER ALL PROPER TRADES HAVE BEEN ENTERED INTO SPARK. POSSIBLE CAUSES:
1. At least one transaction was booked with an incorrect broker tag. Example: A short sale had previously been processed for 1000 shares in Spark. The goal is to flatten the position to 0. In order to accomplish this, a cover short for 1000 shares would need to be booked in Spark. If the original short sale was booked using Jefferies, the cover short to flatten this position would also need to use Jefferies as a broker. If the brokers do not match, two separate positions will be held for a security on a single account. Neither position will be accurate. This in turn will cause breaks in the recon report.
Solution: Open the historical transaction and correct the broker.
PROBLEM 5) SPARK AND BROKER IDENTIFIERS MATCH FOR A GIVEN SECURITY, BUT THERE IS A MISMATCH IN QUANTITY HELD.
POSSIBLE CAUSES:
1. A trade has been booked for the partial amount of the quantity currently held. It is possible that the transaction was processed on Spark, and the broker has not yet updated to reflect the transaction.
Solution: This is a self-correcting error. The break will clear once the broker updates.
2. The broker has correctly updated with a valid transaction, and the transaction has yet to have been booked in Spark.
Solution: The correct transaction will need to be booked to Spark.