Размышление и догадки розничных трейдеров строятся на открытой информации которая есть в интернете. Как там на стороне брокера устроено (какие программы, логика работы, поставщики, маршрутизация, оборудование) никто толком не знает. Черный ящик для клиента. Любые попытки что-то узнать (например о LP) натыкаются на тех. суппорт который в двух словах заворачивает розничного клиента не давая никакой достоверной информации.
Какие-то крохи информации можно получать исключительно через сайты описывающие решения для брокеров.
Вот Rann говорит что часто между ликвидностью и брокером есть посредник.
Я буквально на днях отписал aggregator-fx точка ru
Ликвидность они не предоставляют, а только коннекторы (которые любой программист и так написать может) к источникам и площадкам, плюс весь софт для работы их клиента со своими внутренними клиентами (розничный retail).
Опять же, если компании которые не просто софт и коннекторы поставляют, но у которые готовы и ликвидность от своих партнеров давать, тому же брокеру? Вопрос. Какие это компании, список этих компаний?
Вот Rann об агрегаторе пишет, но конкретней можно было бы?
Какие параметры и функции у агрегатора, что он умеет делать и т.д.
Если кто-нибудь руководство выложил бы по агрегатору с описанием всего, так вообще супер было бы.
А так, разговоры - домыслы - участников дискуссии которые что-то где-то на просторе интернета почерпнули и согласились что этому можно верить, теперь от своего имени вещают.
OTC FX Liquidity Aggregator Classifier:
1. Product name:
2. Description:
3. Complete supply package (components and parts of the System), complete documentation package, availability of Demo version, training courses for the customer’s personnel:
4. Differentiators:
5. Pricing structure (e.g. License, per user, per venue, for A-book, for B-book , etc):
6. Setup time:
7. Architecture (if possible, provide architecture plan as an attachment):
8. Software deployment location (on customer’s servers or on the vendor’s):
9. Server Hardware requirements, server operating system:
10. Available APIs (names, capabilities, performance):
11. Available protocols (inter-module, intranet, extranet) :
a. Currently used and supported by the System’s modules;
b. Possibility to connect external modules using the protocols differing from the System’s ones.
12. Compatibility with FIX:
a. V4.x
b. V5.x
13. Scalability:
a. Max number of LPs that can be connected;
b. Possibility to aggregate liquidities of the other users of the System;
c. Max number of instruments.
14. Technical sustainability:
a. System robustness as a whole;
b. Robustness of the system’s components.
c. System’s self-diagnostics, failure/faults indication.
d. Availability of the System’s automated back-up,
15. Availability of GUI used for System management:
a. Desktop/web;
b. Main sections;
c. Customizability;
d. System performance monitoring;
e. Financial monitoring.
f. Possibility to manage the System from mobile devices.
16. Performance:
a. Number of concurrent live orders supported by the trading engine;
b. Concurrent users threshold;
c. System impact if 1 or N users is a slow consumer;
d. Max quantity of price changes per unit time.
17. Latency (for each part of the System, for hardware-software system only, with no reference to link channels delays. Hardware parameters are to be specified additionally).
18. System’s protection against:
a. Information leakage – protection of the vendor’s business secrets or the client’s private information;
b. Information altering – correction of data reporting or back-end DB;
c. Information destruction;
d. Fraud – protection against unauthorized operations of the vendor’s personnel.
19. Back-office:
a. Storing and archiving the data accumulated by the System;
b. Accumulated data search (from quotes to transactions) with various searching criteria;
c. Reporting system. Name the types of reports available.
d. DB used for reports integration. DB type and scalability. Integration with report-systems and data analysis systems (Crystal Reports, DB’s, OLAP).
e. Possibility to use on mobile devices.
20. Logging (mapping) capability (full and complete documentation orders allocation/execution based on order ID in trading terminal and order ID at each LP for every clients’ transaction, including balance operations, settlements, internal operations etc):
21. Support model:
22. Availability of:
a. A-book;
b. B-book;
c. C-book.
23. Internal matching engine (the system’s users’ limit orders go to aggregated L2 thus enabling the users to trade with each other);
24. Assets classes covered:
25. Types of orders supported:
a. Incoming (list all of them):
b. Outcoming (list all of them):
26. Market Depth Aggregation level based on detailed order book:
a. Based on L1 market data (basic market data that includes the bid price, the bid size, the ask price and the ask size);
b. Based on L2 market data (additional market data includes bid and ask prices and sizes);
c. Logic based levels (logical grouping of aggregated market depths into different levels of liquidity).
27. Availability of Full Market Depth (all open orders on a product);
28. Aggregation criteria flexibility:
a. Aggregate all incoming feeds;
b. Fixed weights on incoming feeds;
c. Per instrument configuration;
d. Rules based on liquidity quality;
e. Per instrument/instrument group rules;
f. Multi-criteria rules.
29. Smart order routing:
a. Dynamic routing (ability to route or split orders based on live market conditions);
b. Adaptive routing (ability to selectively adjust sets of dynamic routing rules based on live market conditions);
c. Best execution facility (routing to the venue that offers the best price for an order);
d. Configurable sweeping (immediate or cancel (IOC) orders are sent to each destination until the parent order is filled or the order is no longer marketable or until a given maximum number of IOC orders are sent).
30. Static routing:
a. Priority per instrument (routing of particular trades to particular venues based on the instrument);
b. Can be specified at run time.
31. Execution performance:
a. Online (dynamic) calculation;
b. Integrated for routing.
32. Risk Management:
a. Margin issues management;
b. “Bad” LP issues management;
c. Circuit Breakers (allows for automated halting of trading and pulling of orders in extreme market conditions);
d. Self-trade Protection (prevents a member from trading with themselves by automatically cancelling either the older or the newer order, or both, or reducing the larger order's size by the size of the smaller order and then cancelling the smaller order);
e. Credit blocks (ability to blacklist specific counterparties on a venue such that quotes and orders from them are not shown) ;
f. Cancel on disconnect (cancels all pending orders if a disconnection from the venue occurs);
g. Fat Finger Protection (protects against placing nonsense orders);
h. Pre-trade limits (controls against trading activity, via pre-defined limits);
i. Failover alerts;
j. Multi-hit protection;
k. Kill Switch (allows a market participant to shut down trading due to a technical glitch, such as a malfunctioning algorithm).
