Client Configurations
Firm Types
In version 8, SpiderRock is implementing a three-level hierarchy to better accommodate the relationship our clients have with their own customers. At the apex of the hierarchy is the Sponsor Client Firm. Below the Sponsor Client Firm is the Core Client Firm. (Note: This would be the default Client Firm from Version 7 and other, past versions.) A Core Client Firm could have a Sub Client Firm (or multiple) underneath it, but this is optional. However, it is required for a Core Client Firm to be associated with Sponsor Client Firm.
A Sponsor Client Firm does not have any trading accounts of their own but does have certain supervisory responsibilities that may include setting up and managing accounts, users, risk controls, and trading routes. This configuration would be more attractive to clients such as prime brokers, brokers/dealers, clearing firms, or advisory umbrella firms with multiple clients.
Note: SpiderRock itself is a Sponsor Firm and all of our direct clients would be configured as a Core Client Firm underneath us.
A Core Client Firm is either a broker/dealer, institutional customer, or an advisory firm. This client firm commonly is the beneficial owner of OR has executing authority for any trading account directly associated with it. As mentioned before, a Core Client Firm is not required to have Sub Client Firms if the structure of the firm is relatively simple. An example of this would be a common pool of accounts and traders operating in a single no-cross group with a single locate pool.
A Sub Client Firm is a trading entity associated with and under the supervision of a Core Client Firm. This would be a trading group within a larger firm or a grouping of accounts for which the Core Client Firm has advisory trading authority. A Sub Client Firm(s) would be established if the structure of a Core Client Firm becomes more complex. For example, if the client has multiple independent trading groups with users who should be blocked from seeing each other’s trading activity or that operate in independent no-cross groups.
Visibility
Core (default) visibility controls within SpiderRock’s platform are configured on a Client Firm level. Users associated with a Sponsor Client Firm will be able to see the information associated with their client firm and the core- and sub-client firms that fall under said firm. Similarly, users associated with a Core Client Firm can see the information and accounts associated with their client firm in addition to the information and accounts of all the sub client firms underneath it. Users at a Sub Client Firm level can only see information and accounts associated with their own client firm.
Note: It is possible to create some exceptions to this general rule by, for example, explicitly listing accounts that are visible to a given user. However, this is NOT recommended and should be avoided if possible. These explicit overrides are not universally implemented throughout the system in the same way as the default behaviors are.
User Types
SpiderRock offers six available user types:
| User Type | Description |
|---|---|
| Sponsor Admin | This user can create and modify Sponsor Users. |
| Sponsor User | This user has controls and visibility over any users underneath its associated Sponsor Firm umbrella. It can create Client Admins and Client Users, create accounts, set or modify limits for a client firm, and other such actions. |
| Client Admin | This user has controls and visibility over their specific client firm (but not to firms above or below it) and any ClientUser types within that same client firm. |
| Client User | The most common user type. This user can have test and/or production accounts assigned to it and is subjected to any controls set by a Client Admin or any Sponsor Admin if there is one present. |
| SRSE User | This user has access only to SRSE. This user would typically be consuming market data and will not be able to send any active orders. |
| M2M User | The Machine-to-Machine user. This user is intended for apps/bots/programs with access only to MLink but not to our UIs or other APIs. |
V7 to V8 Differences
For those familiar with the previous set of user types, here is what the common user types would translate to in version 8 and their resulting configurations:
| V7 Type | V8 Type | Configuration |
|---|---|---|
| ClientTrader | ClientUser | Account Type Control = 'AllAccnts' Order Access = 'Live Orders' Can Cancel Live Orders = Yes |
| ClientRiskAdmin | ClientAdmin | Account Type Control = 'AllAccnts' Can Cancel Live Orders = Yes Can Edit MAR Risk = Yes Can Edit MAR Restricted List = Yes Can Edit Supervisory Risk = Yes Can Edit Stock Locate List = Yes Account Access Control = 'ViewOnly' |
| ClientRiskTrader | ClientUser | Account Type Control = 'AllAccnts' Can Cancel Live Orders = Yes Can Edit MAR Risk = Yes Can Edit MAR Restricted List = Yes Can Edit Supervisory Risk = Yes Can Edit Stock Locate List = Yes |
| ClientSRSEOnly | SRSEUser | Account Type Control = 'AllAccnts' Account Access Control = 'ViewOnly' |
| ClientTestOnly | ClientUser | Account Type Control = 'TestOnly' Order Access = 'TestOnly' Account Access Control = Full access to test accounts; View only for production accounts |
| ClientViewOnly | ClientUser | Account Access Control = 'ViewOnly' |
| C1StageReviewTrader | ClientUser | Same as ClientTrader User Stage Type = 'StageReview' |
| C1StageReleaseTrader | ClientUser | Same as ClientTrader User Stage Type = 'StageRelease' |
| C1StageModifyTrader | ClientUser | Same as ClientTrader User Stage Type = 'StageModify' |
| C1StageLockTrader | ClientUser | Same as ClientTrader User Stage Type = 'StageLock' |
Account Types
There are four account types available for users:
| Account Type | Description |
|---|---|
| Normal | Standard trading accounts with delivery instructions and routing. These accounts can trade, receive clearing records, hold overnight positions, and receive allocations from an Omnibus account. |
| Strategy | Used alongside normal accounts, they hold overnight positions, receive away trades, and participate in allocations but lack routes and delivery instructions. Any trading done must be in tandem with an associated Normal account. |
| Clearing | Risk-only accounts that load start-of-day (SOD) positions, receive away trades, and compute risk but cannot trade or hold overnight positions. |
| Omnibus | Trading accounts with routing and partial delivery instructions that will not rotate overnight or hold SOD positions. They can source allocations to associated Normal or Strategy accounts. |
Each account type can be configured in one of two ways: as a Test account or as a Prod account.
A Test account can send test orders that are viewable on GUIs (Citrix or WebApps) and APIs (SRSE, MLink) but are sent to the SpiderRock simulator rather than the live market. Users can view test orders from other users depending on their user and firm configurations. Test accounts are marked with a "T." at the beginning of the account name for easy identification.
A Prod (or Production) account can send live orders through SpiderRock's gateways and out to market. These accounts are subject to any limits imposed by their respective client firm or any Sponsor/Core client firm above them (if one exists), as well as SpiderRock's own internal trading limits.
Note: Both Test and Prod accounts exist within the same environment.
An account can be configured to be accessed by multiple users. Routing and clearing details are set per account.