Hi everyone,
We are looking to run a secured (over TLS) fix server engine to allow our customers to automatically trade with us via fix protocol.
Up until now, we used to be on the consuming side of the protocol and now we are researching for the best solution to run our own engine as a layer of communication between our customers and our trading system.
Most of our codebase is javascript/node.js but we are open to other technologies.
would appreciate any suggestions or recommendations for implementations or solutions?
Thanks!
As an example, have a look at the German cash market system Xetra (https://www.xetra.com/xetra-en/technology/t7/system-documentation/release10-0). It has a FIX interface that sits between the trading system and the participants. The FIX interface uses ETI (Enhanced Trading Interface) which is the low-latency interface using FIX semantics. Internally, there is a translation between the two interfaces. The closer the internal data model of your trading system is to FIX semantics, the faster this translation can be.
Hello @hanno.klein,
for some reason the referred site is nearly empty. The contents are not visible.
Is this expected?
In addition, may I advise to @tomkeidar to check out QuickFIX/J ?
AFAIK Deutsche Börse started with it as well.
Cheers, Jörg
When I read the question correctly they already have a FIX engine (“our own engine”) but now want to switch from buy side to sell side so to speak…
Cheers,
Chris.
1 Like
@tomkeidar, You mentioned that you’re looking to make secure FIX connections over TLS to allow your customers to trade with you via FIX. And most of your codebase is javascript/node.js. Since you mentioned node.js, I’m assuming that’s what your application server is implemented in. I’m assuming that your customers would be running their own application instance and that the customer application would need to have their own FIX engine to make a FIX connection with you. And you would need to have a FIX engine to service that FIX connection and interface with your node.js application. I’m assuming that you don’t want to develop a FIX engine and want to use and existing one. QuickFIX/J, as mentioned by @jorgthonnes, is a possible open source solution. It supports TLS. There are many commercial FIX engines that support TLS too and have Javascript interfaces.
Another thing to consider is how/where you want to implement the TLS connection. The TLS connection can be established by the FIX engine or it could be made by a device or software package through which the FIX connection is routed. Some possibilities are:
- The TLS connection with the customer is established by the FIX engine.
- The FIX engine makes unencrypted FIX connection through a VPN, the traffic sent through the VPN is encrypted via TLS or other protocol, and unecrypted at the other end.
- The FIX engine makes TLS FIX connection through a VPN, the traffic sent through the VPN also encrypted by the VPN.
- The FIX engine uses a separate device or software (such as an firewall, F5, etc.). The FIX engine makes a connection to the device (either encrypted or not), the device unencrypts the traffic, and then device then make a TLS connection to the customer. The TLS connection to the customer is handled by the device.
There are pros and cons with all of these possibilities.
If you have your FIX engine make the TLS connection, this is simple, but you will need to keep your FIX engine and the software libraries it uses for TLS up to date.
Security is constantly evolving. Encryption ciphers may be discovered to be insecure, vulnerabilities may TLS protocol versions, vulnerabilities may be found in the libraries which are used to build the solution. Keeping the software upto date may sound simple, but that depends on how many systems your org has, how many different vendors, and how quick your org can deploy changes.
If routing the traffic through a VPN, the VPN is handling the encryption. Your main focus is to keep the VPN software up to date. But with a VPN, you typically need a device/software on your side and another device/software a the customer site. Administrating the device/software as customer site may be complicated.
If routing the traffic through a device/software like a firewall, F5, etc. The TLS connection is to the customer is handled by the device/software. You would have nothing to administer at the customer site, but the customer must have something that can make the appropriate TLS connection. Your focus would be to keep your device/software/firewall/F5 upto date.
1 Like
Sorry, I picked version 10.0 that is not final yet. Please use the landing page for version 9.1 and click on “FIX Interface” from there.
1 Like