FIX messages for basic admin tasks

, ,
1

Imported from previous forum

2

Hi all,

As far as I know, FIX protocol brings messages to deal with pre-trade, trade and post-trade stages in almost any financial environment. However, I’d like to extend the use of FIX even to deal with basic administration tasks (e.g. opening new account for a new client, transfer of funds between different accounts of one client, etc…).

Since FIX does not support this kind of tasks, my idea is to modify an open source FIX engine (e.g. QuickFIX) to add new messages for this. It shouldn’t be a big deal. This way, we could have a seamless integration of all tools/clients within our IT infrastructure.

Any advices here will be more than welcome.

Thanks and Regards.

3

[ original email was from Chris Snell - Chris.snell@patsystems.com ]
> Hi all,

As far as I know, FIX protocol brings messages to deal with pre-trade, trade and post-trade stages in almost any financial environment. However, I’d like to extend the use of FIX even to deal with basic administration tasks (e.g. opening new account for a new client, transfer of funds between different accounts of one client, etc…).

Since FIX does not support this kind of tasks, my idea is to modify an open source FIX engine (e.g. QuickFIX) to add new messages for this. It shouldn’t be a big deal. This way, we could have a seamless integration of all tools/clients within our IT infrastructure.

Any advices here will be more than welcome.

Thanks and Regards.

Hi

You can use Registration Instructions (o) message in FIX for account creation and you can use a Position Maintenance Request (AL) in FIX for tranferring of funds between accounts.

Chris

4

Hi

You can use Registration Instructions (o) message in FIX for account creation and you can use a Position Maintenance Request (AL) in FIX for tranferring of funds between accounts.

Chris

Thank you Chris. Very useful. I’ve found those messages on FIX 4.4.

Kind Regards,
Mustafa

5

There is a standard process for FPL members to extend the protocol with new messages, fields or valid values to close gaps (http://www.fixprotocol.org/documents/2341/FIX%20Protocol%20Gap%20Analysis%20Proposal%20Template%20r2.1.zip).
QuickFIX uses the FIX Repository to support standard FIX messages and should not be extended to include messages not contained in the official FIX Repository. “Open source” should relate to the engine software and not to the supported message types. New functionality with relevance to many FIX users should always be subject to a submission to FPL for review and approval. This ensures a consistent quality of such extensions. Often enough the functionality is already available and no extension is needed. This seems to be the case here as well, at least some of it.
Regards,
Hanno.

Hi all,

As far as I know, FIX protocol brings messages to deal with pre-trade, trade and post-trade stages in almost any financial environment. However, I’d like to extend the use of FIX even to deal with basic administration tasks (e.g. opening new account for a new client, transfer of funds between different accounts of one client, etc…).

Since FIX does not support this kind of tasks, my idea is to modify an open source FIX engine (e.g. QuickFIX) to add new messages for this. It shouldn’t be a big deal. This way, we could have a seamless integration of all tools/clients within our IT infrastructure.

Any advices here will be more than welcome.

Thanks and Regards.

6

There is a standard process for FPL members to extend the protocol with new messages, fields or valid values to close gaps (http://www.fixprotocol.org/documents/2341/FIX%20Protocol%20Gap%20Analysis%20Proposal%20Template%20r2.1.zip).
QuickFIX uses the FIX Repository to support standard FIX messages and should not be extended to include messages not contained in the official FIX Repository. “Open source” should relate to the engine software and not to the supported message types. New functionality with relevance to many FIX users should always be subject to a submission to FPL for review and approval. This ensures a consistent quality of such extensions. Often enough the functionality is already available and no extension is needed. This seems to be the case here as well, at least some of it.
Regards,
Hanno.

Thanks for your comments Hanno. My organization is not currently an FPL member, therefore where not entitled to submit RFC’s, I pressume. However, maybe we will join FPL in the near future.

On the other hand, once I had a look to the messages suggested by Chris, I am pretty sure now that we do not need any extension.

Have a nice day!
Mustafa