Cone8
 ( 24.56% )
- ago
This is a REALLY good idea. Write base provider for FIX and then inherit it to pump out a dozen broker providers. I think in most cases, it's only a matter of changing a settings file, and you're automatically connected to another FIX broker - brilliant!

I was looking into this a couple years ago and found this library, which makes it really easy to implement.
http://quickfixn.org/

Example of a FIX config file:


[DEFAULT]
ConnectionType=initiator
HeartBtInt=30
ReconnectInterval=1
FileStorePath=c:\fixfiles
FileLogPath=log
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=N
SocketConnectHost=localhost

[SESSION]
BeginString=FIX.4.2
SenderCompID=CLIENT1
TargetCompID=FixServer
SocketConnectPort=5001
9
1,488
6 Replies

Reply

Bookmark

Sort
- ago
#1
QUOTE:
REALLY good idea. Write base provider for FIX and then inherit it to pump out a dozen broker providers.

I totally agree, especially since FIX is the wave of the future brokers would be using. It's not a question of "if" but "when". Something like

CODE:
namespace WealthLab.MyBroker {    private class FixConfigDef    {       //default settings       int heartBtInt = 30;       string fileStorePath = @"TEMP\fixfiles";       ...       //overriding constructors       FixConfigDef(int heartBtOverride)       {          heartBtInt = heartBtOverride;       }    }        public class MyBrokerProvider : FixBase    {       public MyBrokerProvider(..., ...) : base(new FixConfigDef(25))       {       }    } }
And it's even possible to place "FixConfigDef" inline as ExcelReader does (although I find that approach a bit confusing). See the new ExcelReaderConfiguration() definition at https://github.com/ExcelDataReader/ExcelDataReader for an example.

In addition, some of these FIX functions need to be "virtual" so they can be overridden by the MyBrokerProvider because the broker may not support all the FIX functions "at this time". So there's a need to override some of the FIX implementation with non-FIX traditional calls to fill in the gaps.

Although this is a flexible approach, it is somewhat advanced. But those writing broker providers are likely experienced oops programmers, so they can appreciate the flexibility of this inheritance approach with virtual methods.
0
Glitch8
 ( 7.81% )
- ago
#2
From what I read FIX is mainly used by Forex brokers. I don't see many brokers moving to FIX, they're all putting out REST APIs.

How would we even develop and test this proposed FIX extension, does anyone have an account with a FIX connected broker?
0
Cone8
 ( 24.56% )
- ago
#3
IB has FIX too.
I haven't look at FIX in a long time, but I'm not sure if passing account info is part of the protocol. If we can't get cash and buying power from the broker, I don't think it's worth pursuing for WealthLab.
0
Glitch8
 ( 7.81% )
- ago
#4
Here's the confidential FIX API PDF that came up on their web site with a simple Google search,

https://www.interactivebrokers.com/download/IB_FIX_Manual.pdf
0
Glitch8
 ( 7.81% )
- ago
#5
But isn't this all institutional facing? Would any of our retail clients be able to use a FIX Extension to connect to an account? For now, I'll decline this one and we can re-open if/when we get more clarity.
0
- ago
#6
Re: IB has FIX too.

But IB has REST implementing which (over FIX) would seem to be more practical given its wide user base? Implement IB Client Portal (REST) API to bypass TWS
0

Reply

Bookmark

Sort