# 2. About the Platform
# 2.1. Platform Overview
In simplified terms, the platform consists of trading robots and a system for managing them. From the client's perspective, the robot management system includes the API and the website https://bot.fkviking.com/ (opens new window). The API is the only programmatic interface that enables communication between the user and the robots. The website https://bot.fkviking.com/ (opens new window) uses the same API available to third-party developers for implementing their own custom user interfaces. The platform implements a user permission system by assigning specific roles to each user. Access to the platform via the API or website is governed by restrictions imposed by the role under which authentication is performed. It is assumed that each user has only one account on the platform, as the role-based model allows simultaneous access to multiple robot portfolios, even if the robots belong to different companies. Below are the system requirements for client devices, along with brief descriptions of the robot, the website interface, and the role-based model.
# 2.2. System Requirements
The primary means of interaction between users and robots is the website https://bot.fkviking.com/ (opens new window). The site is available in desktop and mobile versions. Although the mobile version provides functionality close to the desktop version, it is less convenient due to the limitation of displaying only one widget at a time. Simultaneous display of multiple widgets in the desktop version requires transmitting and storing large amounts of data. Therefore, it is recommended to use the desktop version on a computer meeting the following requirements:
- A processor with at least four cores (not below Intel Core i3-10100 or AMD Ryzen 3 3100);
- At least 8 GB of RAM;
- Internet connection speed of no less than 30 Mbps;
- An up-to-date version of a modern browser (Google Chrome, Mozilla Firefox, Microsoft Edge, Safari, Opera) with JavaScript enabled and ad/script blockers disabled (the Viking platform does not contain ads, but such extensions may negatively affect page performance);
- Firewall must allow access to the website https://bot.fkviking.com/ (opens new window).
Note that these requirements assume a scenario where only one browser window with a single tab open to https://bot.fkviking.com/ (opens new window) is running, and the entire internet bandwidth is dedicated to data exchange between the site and the server. If multiple instances (browser tabs) of our site are used, if the internet connection is shared among multiple devices and/or applications, or if other resource-intensive applications (trading terminals, spreadsheets, video players, computer games, etc.) are running in parallel, the overall system requirements increase. Additionally, using VPN or proxy servers may reduce the effective internet channel bandwidth. The requirements listed above are recommended; it is possible to use the desktop version on a computer that does not meet these specifications, but in such cases, the interface may experience "freezing" when interacting with certain widgets.
# 2.3. Brief Description of the Robot
Each robot can trade multiple identical algorithms. An algorithm, along with all its settings, will hereafter be referred to as a portfolio. Each robot's portfolio must contain the financial instruments intended for trading or for use in calculations. A portfolio must contain at least one instrument, and all instruments within a portfolio are unique.
One of the instruments in the portfolio must be marked with the Is first flag; this instrument will be referred to as the main instrument or the first leg of the portfolio. Instruments in the portfolio not marked with the Is first flag will be referred to as the second leg of the portfolio. Each robot's portfolio has parameters that apply to the entire portfolio; these are called portfolio parameters. In addition, there are parameters set individually for each instrument in the portfolio; these are called instrument-specific portfolio parameters. Also defined for the entire portfolio are notification parameters (Notifications).
There are several additional parameters set for each instrument on every transaction connection (instrument position parameters and currency position parameters). Parameters are divided into editable ones (i.e., actual settings) and display-only or calculated ones (e.g., financial result).
For greater flexibility, certain portfolio and instrument parameters can be defined as formulas written in the C++ programming language.
For each of the robot's portfolios, you can select the Type of the algorithm to be used. The robot’s primary algorithm is arbitrage-based. Bid and ask prices for the main instrument are generally calculated based on the prices of other instruments in the portfolio. Two operating modes are supported. In quoting mode (the Quote flag is enabled), after trading is activated, bid and ask orders are maintained in the order book for the portfolio's main instrument. The quoting order is moved when certain conditions are met, such as when the price of the placed order deviates from the calculated price. If quoting is disabled, orders for the main instrument are placed only upon receiving a signal (i.e., when a specific condition is satisfied).
Orders for second-leg instruments are placed after a trade is executed on the first leg. The direction of orders for second-leg instruments is determined by the direction of the trade on the first leg and the value of the On buy parameter of the corresponding instrument.
The robot can be configured either to place second-leg orders after every first-leg trade, or to place them less frequently. The volume for placing an order on each second-leg financial instrument is calculated based on the current portfolio position on the first leg and the Count parameter values of both financial instruments, such that the ratio of the "new" position of the given financial instrument (which will exist after execution of the yet-to-be-placed, but currently being submitted, order) to the first-leg position equals the ratio of the Count parameter of the second leg to the Count parameter of the first leg. When determining the "new" position for a financial instrument in the portfolio, any outstanding unexecuted orders are assumed to be fully filled.
All orders placed by the robot are limit quote orders on all supported exchanges.
It is highly recommended not to manually remove orders submitted by a robot from the terminal, except in cases where the order is "stuck" in the robot, that is, when for some reason the robot no longer tracks this order.
# 2.4. Brief Description of the Interface
The main interface page consists of a set of table-widgets located in the dropdown menu Widgets. All widgets can be opened and closed in any quantity and order, except for the Robot logs widget, which is always open and only one instance is allowed.
During robot operation, various "errors" may occur when placing or canceling orders. Such situations are not considered abnormal robot behavior and may be caused by factors unrelated to incorrect robot operation—for example, insufficient funds in the client's account. All "errors" and additional program-related information can be viewed in the Robot logs widget. Some messages that arrive too frequently will not be displayed individually; instead, they will appear once every 10 seconds and will be marked at the end with the suffix xN, where N is the number of grouped messages not shown. Certain commands that would inevitably be rejected by the exchange are not sent to the exchange at all. Such "errors" are marked with the postfix _LOCAL.
Historical logs can be viewed using the Robot logs history widget. In the widget settings, you can select one of the predefined periods: today, yesterday, 5 days, week, 10 days, month—or manually specify a custom period with minute precision.
The widgets Robot logs, Robot logs history, Financial result for today, Finres history, Deals for today, Deals history, and Trade connections orders display the user's local time.
The main robot interface includes an important messaging feature that displays messages as modal windows, blocking user interaction with the site until the user confirms via a button that they have read the message. If the user is online, the message appears immediately after being sent. If the user is offline, the message will appear upon their next login. If a particular message occurs no less than once every 20 seconds and continues for 10 minutes, the user will receive a popup notification about it. This type of notification appears on top of all other windows and remains visible until the user clicks ok, confirming they have read it. The initial timeout for receiving such a notification is 10 minutes, then 30 minutes, 1 hour, 3 hours, and 6 hours, after which it resets back to 10 minutes, and so on. The list of sent notifications is also available for viewing in the Notifications menu in the user's personal cabinet under the icon in the upper-right corner.
Note that all widgets are customizable. Column order can be changed, column widths adjusted, and unnecessary columns hidden via Columns. It is possible to open multiple instances of the same widget with different settings. The configured workspace can be saved in Workspaces and later loaded on other devices. Additionally, there is functionality to export and import Workspaces via file. This allows users with multiple roles to transfer configured Workspaces from one role to another.
To begin working with the robot, you must activate the required data connections for market data and add necessary transaction connections. Market data connections are activated in the Data connections widget. Transaction connections are added in the Trade connections widget. To create a portfolio, use the Portfolios table widget.
# 2.5. Brief Description of the Role Model
A role-based model is used to manage user access rights on the platform. To understand it, it is necessary to first introduce some entities and clarify connections between them. In addition to robot, portfolio, and user, "company" entity is introduced. This entity is used as a binding point for robots, i.e., a robot is created for a specific company and belongs to it thereafter. Creating a robot without specifying a company is impossible. A portfolio is created by a user in a specific robot. A user who creates a portfolio becomes its owner (creator) and automatically gains rights to that portfolio. Thus, a user has rights to all portfolios they have created in a given robot. Access to a portfolio created by a user can only be revoked together with a robot.
A user can have same role in different companies. Moreover, in each of companies, they can have one or several roles. Currently, besides Demo role, Trader, Head of traders, and Head view only roles exist. Trader role is intended solely for performing trading operations. One robot can be accessible to multiple users with Trader role. A user under Trader role has access only to those portfolios of robots available to them for which they are owner (creator), and to those to which explicit access was granted to them by Head of traders.
Thus, robots are now linked to users not directly, but through an intermediate layer in the form of a company: robots belong to a company, users receive roles in a company, in accordance with which they can be assigned robots and portfolios from among those belonging to a company.
During authorization, a user specifies a role under which authorization is performed. Authorization is performed under a role without specifying a company, i.e., after authorization, a user will gain access in accordance with a specified role in all companies where this role is assigned to them.
# 2.5.1. Demo
After registration, all users automatically receive Demo role in public company. This is a special role and a special company. Under this role in this company, only free robots (with Free specified in their name) with virtual trading are available. In other companies, Demo role is not available. All other roles are assigned to a user within a specific, already "real", company.
Demo robots allow you to explore part of platform capabilities for free, but with a number of restrictions:
- All necessary market data connections are configured in them. Changing state of market data connections (
Enabled/Disabled) is prohibited. - Creating trading connections is prohibited, because such robots are not intended for live trading. During initial setup of such robots, Connection setup section should be skipped.
- Historical mode is not available, because such robots are multi-user.
- Only virtual portfolios can be created.
- Using C++ formulas is not available.
# 2.5.2. Head of traders
Under Head of traders role, both trading and administrative operations can be performed.
Head of traders can assign Trader, Head of traders, and Head view only roles to themselves and other users within a company where they are Head of traders. In particular, they can grant access to robots and portfolios to users who have Trader role in a company. Users with Head of traders and Head view only roles do not need to choose available robots and portfolios, they have access to all robots and portfolios within a company by default. Access is granted in Users widget, available only to users with head of traders/Head view only roles.
In addition, a user with Head of traders role gets a portfolio parameter from Anti "Spam" group called max_not_hedged_adm. This parameter sets maximum possible value of max_not_hedged parameter. Restriction applies to a portfolio on which restriction is set.
# 2.5.3. Head view only
Head view only is a read-only counterpart of Head of traders role, under this role same data is visible as under Head of traders, but modification of this data is prohibited. Under Head view only role, only own user settings can be edited.