Altaira supports the following instruments on all exchanges, from plain-vanilla to the most structured and exotic:
All instruments are supported by the user's choice of Altaira pricing models, custom proprietary models, Numerix, etc... |
|||||||||||
Altaira provides the following usability features:
|
|||||||||||
|
Two paradigms exist with regard to the burden of processing: Thick-client (i.e., "Client-side" where the processing is done entirely on the client machine) and Thin-client (i.e., "Server-side" where processing is done on one or more server machines). Although Thick-client applications typically have the benefit of a rich interface (GUI), heavy computational use can not only degrade a system's overall performance, but sometimes puts the operating system into a state of "resource starvation" — making it totally unresponsive.
Altaira offers the best of both worlds by providing a rich GUI while off-loading the computational burden to multi-threaded "agents" either on a single or clustered server. The benefits of this approach are concurrent processing, load balancing, and flexible scalability ("scale-up" and/or "scale-out"). The system uses a "divide and conquer" approach to large pricing jobs (e.g., 20,000 structured product deals) by breaking each "job" into smaller "tasks." Drones continually compete for tasks to process and cache much of the data locally. "One-off" pricing jobs are performed synchronously and are load-balanced using IP (Internet Protocol) routing. "Batch" jobs are performed asynchronously so a trader has the freedom of revaluing his entire book while performing other tasks — or even logging out to go to a meeting and checking the results later.
A new user installs the software using Click-Once Deployment. Presuming that he or she has been given sufficient rights by the administrator, the user will see a tree-based view of the portfolio that is customized for the user. When a trade is opened or created, trade details transmitting back to the client application via compressed XML. When applying changes, the client application transmits the deal changes to the web server which routes the deal — and causes it to be saved by the database using a highly efficient recordset comparison. For "batch"-type operations (i.e. Shock, VaR, MTM), the job is queued to the database as a collection of individual tasks. "Drones" (or worker processes) continually poll the database for tasks to perform, and are served tasks in a specific priority order (using the SQL Service Broker). Since much of the data is cached locally, each drone checks for update flags before either refreshing data, or processing the data in the local cache. Each drone is multithreaded, and multiple drones can run concurrently on a single machine. The client application continually polls the database for completed jobs. This polling uses very little overhead and allows the user to submit several jobs which can run concurrently. Because of this distributed computing model, responsiveness is crisp — and jobs (with their corresponding results) can be accumulated or deleted at at a predefined interval or on-demand. Quotes are posted to the database in a separate process which includes its own logic. In addition, "quote sets" (or "snapshots" of the current quotes) can be created either on a scheduled interval or on-the-fly. Since all system functions are exposed via web services, companies have the choice of extending their existing system(s) or customizing the Altaira system — using either native .NET objects or Web Services (for cross-platform compatibility with UNIX, etc...); this translates to virtually unlimited customization and extensibility. Not satisfied to be simply better, we are driven to be the best. Accordingly, years have been spent both in theoretical design and real-world "make-or-break" testing of emerging technologies, protocols, formats, and algorithms... The result is Altaira. |
|||||||||||