Drift Report

The Drift report is used by clients to ensure that all accounts were traded successfully. The report contains five utilities to find accounts meeting user-specified requirements:

• WHOCDA Finds accounts that had recent client-directed activity
• WHOMMREALLOC Finds UMA accounts that are linked to a master model that had a recent update
• WHOSLEEVECHANGE Finds UMA accounts that are linked to a master model where at least one sleeve model had a recent update
• WHOSMAREALLOC Finds non-UMA accounts that are linked to an SMA model that had a recent update
• WHOUNSUSPENDED Finds accounts that were previously in a suspended account status

These account sets can be accessed at any available account selection prompt (FEND) on APL. Each of the utilities will prompt the user for the following information:

• A start date for the look-back period. The standard APL date prompt (CHKDATE) is used
• An account selection to consider. The standard APL account selection prompt (FEND) is used

WHOCDA

This function will search APL’s trade blotter file (<client>BLT) for receives and delivers on or after the start of the look-back period as well as APL’s cash blotter file (<client>GLB) for RCV, DLV and DLVINC transactions on or after the start of the look-back period. Any account that meets either of these requirements in the trade blotter file or cash blotter file that also exists in the user’s response to the account selection prompt will be returned.

For example, if a user wanted to find all accounts that had client activity for the past two business days for RR EQ 11 accounts then the user would follow the steps shown in the screenshot below:

WHOMMREALLOC

This function will scan APL’s master model allocation file (MDPRULES) for any changes. To speed up this process, the function uses Dyalog’s component time-stamping utility ([]FRDCI) to determine the last time that a model was updated. This means that we capture the actual date of the model change as opposed to the effective date of the model. This also means that if a user saves a master model but doesn’t actually update the target allocations the model would still be included.

Once master models that were modified on or after the start of the look-back period are determined, the function returns the list of accounts associated with these master models that also exist in the user’s response to the account selection prompt to the calling function.

For example, if a user wanted to find all RR EQ 11 accounts that are associated with a master model that was modified in the past two business days then the user would follow the steps shown in the screenshot below:

Note: Only accounts currently associated with the master model that was modified will be included by WHOMMREALLOC. No attempt will be made to historically associate a master model with a set of accounts from a previous day.

WHOSLEEVECHANGE

This function will scan APL’s sleeve model allocation file (<client>MDPR) for any changes. This utility must also be sensitive to the fact that some sleeve models may be associated with an SMA model. For sleeve models that are associated with an SMA model the SMA model change date must be applied rather than the sleeve change date.

To speed up this process, the function uses Dyalog’s component time-stamping utility ([]FRDCI) to determine the last time that a sleeve model was updated. For SMA models, the DATE field in the SMA model database (DESPCT) will be used to determine the last time that an SMA model was updated. Once sleeve models that were modified on or after the start of the look-back period are determined, the utility determines the master models that hold these sleeves. Finally, it will determine the accounts associated with these models that exist in the user’s response to the account selection prompt and will return the list to the function.

For example, if a user wanted to find all RR EQ 11 accounts that are associated with a master model that contains a sleeve modified in the past two business days then the user would follow the steps shown in the screen shot below:

Note: Only accounts currently associated with the master model that contains a sleeve model that was modified will be included. No attempt will be made to historically associate a master model with a set of accounts from a previous day.

WHOSMAREALLOC

The function scans APL’s SMA model file (DESPCT) for any changes. The DATE field in this file can be used as a reliable change date. Once SMA models that were modified on or after the start of the look-back period are determined, the function will determine the accounts associated with these models that also exist in the user’s response to the account selection prompt and will return the list to the function.

Note: It is assumed that the same APL field that links a UMA account to a UMA master model will also be used to link an SMA account to an SMA model.

For example, if a user wanted to find all RR EQ 3 accounts that are associated with an SMA model change that was modified in the past two business days, they would follow the steps shown in the screen shot below:

Note: Only accounts currently associated with the SMA model that was modified will be included by WHOSMAREALLOC. No attempt will be made to historically associate an SMA model with a set of accounts from a previous day.

WHOUNSUSPENDED

This function scans APL’s AUDITTRAIL files for accounts that had a change to the RR field on or after the look-back period and where the account was in a suspended status. WHOUNSUSPENDED determines the list of accounts that were in a suspended status that also exist in the user’s response to the account selection prompt and will return the list.

Note: It's assumed that an account was in a suspended status if the account shows a “BEFORE” RR code of 66, 67, 68, 69, 70, 71, 72, 73, 74, 76, 77, 79, 85, 86, 87 or 88 in AUDITTRAIL.

For example, if a user wanted to find all RR EQ 11 accounts that became unsuspended in the past two business days, they would follow the steps shown in the screen shot below:

Running the Report

Once the accounts are filtered using one of the function described above, the next step is to create the report.

The private (SubPA) function AISNEWDRIFT creates a position drift and sleeve drift report. Each set of reports contains an APL-style (.LRP) report and a csv file.

Note: The new report can only be run as of CUREXDATE since we don’t store historical SMA model or sleeve model data.

The following prompts will be presented to the user when running AISNEWDRIFT:

1. Include Accounts That Were Associated with a Different Model? YES / NO
2. Include Accounts That Are Associated with a Master Model Reallocation? YES / NO
3. Include Accounts That Are Associated with a Sleeve Reallocation? YES / NO
4. Include Accounts That Are Associated with an SMA Model Reallocation? YES / NO
5. Include Accounts That Had Client Directed Activity? YES / NO
6. Include Accounts That Became Unsuspended? YES / NO
7. Exclude Positions That Have Drifted by Less Than 1 Share? YES / NO
8. Enter Absolute Position Drift
9. Enter Relative Position Drift
10. Which Drift Tolerance(s) Should Be Used? Possible answers are ABSOLUTE, RELATIVE or BOTH
11. Enter Start Date for Model Changes.
    This prompt is only presented to the user if the response to prompt (1) above is “YES”. The standard date prompt (CHKDATE) is used. The default date is CURPRDATE
12. Enter Start Date for Master Model Reallocations.
    This prompt is only presented to the user if the response to prompt (2) above is “YES”. The standard date prompt (CHKDATE) is used. The default date is CURPRDATE
13. Enter Start Date for UMA Sleeve Reallocations.
    This prompt is presented to the user if the response to prompt (3) above is “YES”. The standard date prompt (CHKDATE) is used. The default date is CURPRDATE
14. Enter Start Date for SMA Model Reallocations.
    This prompt is only presented to the user if the response to prompt (4) above is “YES”. The standard date prompt (CHKDATE) is used. The default date is CURPRDATE
15. Enter Start Date for Client Directed Activity.
    This prompt is only presented to the user if the response to prompt (5) above is “YES”. The standard date prompt (CHKDATE) is used. The default date is CURPRDATE
16. Enter Start Date for Unsuspended Accounts.
    This prompt is only presented to the user if the response to prompt (6) above is “YES”. The standard date prompt (CHKDATE) is used. The default date will be CURPRDATE
17. Enter Full List of Accounts to Consider.
    The standard APL account selection utility (FEND) is used. The list is filtered based on the utility used
18. Enter Accounts That Should Always be Included.
    The standard APL account selection utility (FEND) is used. Accounts included in this list should always be considered by the drift report and should not be pushed through the filters discussed in the first five stories of this requirement
19. If the report is being run online and within a Windows universe, the user will be prompted with all uncommitted blocks that exist in the universe. The user can then select any, all or none of the uncommitted blocks to be included. If uncommitted blocks are included then these blocks will be included in an account’s position and cash balances as if the blocks were committed blocks. If no uncommitted blocks exist for the given universe then this prompt will not appear

At this point, the report has all the information needed from the user to start producing drift reports. If the user chose to filter accounts for consideration, the following filters will be applied depending on the user’s input to the various prompts:

• If filtering on accounts that are associated with a different model, then accounts that have a date in MODCDT on or after the look-back period will be considered
• If filtering on master model reallocations, then WHOMMREALLOC will be applied to find appropriate accounts.
• If filtering on sleeve reallocations, then WHOSLEEVECHAGE will be applied to find appropriate accounts
• If filtering on SMA model reallocations, then WHOSMAREALLOC will be applied to find appropriate accounts
• If filtering on client directed activity, then WHOCDA will be applied to find appropriate accounts
• If filtering on accounts that became unsuspended, then WHOUNSUSPENDED will be applied to find appropriate accounts

The report will cycle through each account comparing current holdings to the model position. For SMA accounts, this report will assume that the corresponding model is defined in the same field used to associate UMA accounts to UMA master models. When determining positions, all committed trades as well as any uncommitted specifically included by the user will be included. If an account is only included for consideration because of a sleeve reallocation then only the sleeves that were modified since the look-back period will be considered. All other sleeves in the account will be ignored. If an account is included because of a sleeve reallocation and another filter, such as due to client directed activity, then the entire account will be considered.

Only positions and cash that meet the thresholds for absolute and/or relative drift, as defined by the user, will appear on the output reports. When testing for drift violation it will be assumed that all drift is a positive value. In other words, if the absolute drift threshold is 1% and two positions deviate from the model target by 2% but one position is over weighted and the other position is under weighted then both positions will appear on the output reports. Relative drift is defined as 100 x Absolute Drift / Target Position. If the target position for a security is 0%, i.e.: this is a non-model position, then the relative drift will be assumed to be 100%.

If the user selected to ignore positions with a drift of less than one share then these positions will be ignored even if absolute and/or relative drift is violated. This can happen in low value accounts/sleeves that have a target position for a high priced security, such as AMZN. In these scenarios, the account/sleeve may not be able to purchase a full share of the high priced security due to cash constraints and rounding. However, since these positions have not drifted by more than one share then the position will not be displayed on the output reports if the user elected to ignore these positions.

POSDRIFT Report

Each position that violates drift, taking in to consideration the opportunity to exclude positions that drift by less than one share from target, will appear in this report. The APL-style position drift report is called POSDRIFT.LRP. The position drift csv file is called POSDRIFT.CSV. The two reports have the same basic fields but the csv file contains additional data points. The header will differ between the two reports. The POSDRIFT.LRP report has typical APL report headers while the POSDRIFT.CSV file has header names.

Both the PRT and SCV POSDRIFT file contain the following columns:

The CSV file contains these additional columns:

Sleeve Drift Report

Information for each UMA account considered by this report will be written to the report. All sleeves held in the account or the corresponding model are included. The APL-style sleeve drift report is called SLEEVEDRIFT.LRP. The sleeve drift csv file is called SLEEVEDRIFT.CSV. Each report will have the same fields but the headers will differ. The SLEEVEDRIFT.LRP report has APL report headers while the SLEEVEDRIFT.CSV file has header names.

The report contains the following columns: