Hi,
I would like to get some hints about modeling a special type of orders to transfer money from and to a settlement account used to save customers money available for trading.
The customer has a portfolio of securities and a dedicated settlement account to provide the money to buy new securities.
So we have two types of orders: orders to buy or sell securities and orders to withdraw money from the settlement account (or vice versa).
I would like to user a FIX NewOrderSinge message but I am not sure which fields to use to indicate the different category of orders. Even another FIX message type may be suitable.
Any hints welcome !
Cheers, Jörg
FIX is not ideally suited to moving funds - SWIFT, Fedwire or some other funds transfer network will need to come into play. But the FIX NewOrderSingle(35=D) message could be modeled for the customer to instruct its IM to deposit to or withdraw from its settlement account. Here is a sample of the necessary tags:
<Instrument>
Symbol(55)=[N/A]
SecurityType(167)=CASH
Side(54)
1 Buy (to transfer funds into the cash account at the IM)
2 Sell (to withdraw funds from the cash account at the IM)
<Parties>
NoPartyIDs(453)=3
PartyID(448)=<customer id at the IM>
PartyIDSource(447)=D (proprietary)
PartyRole(452)=13 (Order origination firm)
<PtysSubGrp>
NoPartySubIDs(802)=1
PartySubID(523)=<settlement account number>
PartySubIDType(803)=10 (Settlement account number)
PartyID(448)=\<bank identifier, e.g. swift or fed routing>
PartyIDSource(447)=B (BIC) or C (Market participant ID)
PartyRole(452)=109 (Beneficiary's bank)
PartyID(448)=\<customer's bank account number>
PartyIDSource(447)=D (proprietary)
PartyRole(452)=32 Beneficiary
\<PtysSubGrp>
NoPartySubIDs(802)=1
PartySubID(523)=\<customer's name>
PartySubIDType(803)=1 (Firm) or 2 (Person)
1 Like
Thanks for the detailed reply, Dean!
So basically the SecurityType=CASH is what I was looking for.
Cheers, Jörg
Suggest to also have a look at the CollateralRequest (MsgType=AX) which may make it clearer that it is not an order to trade something. Use CollAsgnReason(895)=8 (Transfer deposit) and 9 (Transfer withdrawal) together with SecurityType(167)=CASH. Both options not ideal as Dean already pointed out. FIX does not support plain vanilla payment instructions.
1 Like
Thanks for the reply, Hanno and good to read you again 
Basically, we want to model our internal language according to the FIX standards if possible and useful.
The FIX interface depends on what our customers provide.
Cheers, Jörg
1 Like
Hello @hanno.klein,
searching for settlement I found my own thread 
I hope you are fine.
Still dealing wish cash my requirements changed:
Now I want to specify two account types for an order to buy or sell funds.
The first account A describes the account for the security asset.
The second account B describes the cash account to be used.
Use case:
Buy funds to account A withdrawing cash from account B
or
Sell funds from account A depositing cash to account B
While I possibly could use the 1/Account field for the account 1 in the above case,
I wonder what I should use for account B and whether the usage of 1/Account is
correct and suitable at all.
Looking forward reading from you, Jörg
@jorgthonnes, I think the only option you have is to again use the Parties component, possibly together with PtysSubGrp. For example, PartyRole(452)=91 (Settlement Account) and attach the sub-component with PartySubIDType(803)=15 (Cash account number) or 23 (Cash account name).
Or you identify the buyer/seller with PartyRole(452)=1 (Executing Firm) and attach two subcomponents with a) PartySubIDType(803)=10 (Securities account number) or 22 (Securities account name) and b) PartySubIDType(803)=15 (Cash account number) or 23 (Cash account name).
Or you only identify the accounts with two instances of Parties but without the subcomponent, i.e. a) PartyRole(452)=24 (Customer account) and b) PartyRole(452)=126 (Contra customer account). Semantically, that may be a stretch if both account belong to the same party.
The best design depends on the other information related to parties that you need to convey in the same message. Hope it helps you to find a good solution!
@hanno.klein, thanks for coming back to me. It seems there was a lot of FIX working group stuff to be done.
Indeed, looking back at the post of @deankauffman and FIXimate, I find Parties component most suitable. The second suggestion seems to be most suitable to me, since it is symmetric:
453/NoPartyIDs=1
448/PartyID=<<some name>>
447/PartyIDSource=D (Proprietary)
452/PartyRole=1 (Executing Firm)
802/NoPartySubIDs=2
523/PartySubID=A
803/PartySubIDType=10 (Securities account number)
523/PartySubID=B
803/PartySubIDType=15 (Cash account number)
For the 448/PartyID I have to provided a fixed dummy name because we do not care here.
The only other information we have to transport is the so-called “contract” which bundles several accounts and is the legal entity belonging to the customer. Possibly, we could use 448/PartyID here?
But with a different role, I guess. How about 24 (Customer Account)?
Cheers, Jörg (and regards from Valentin)
@jorgthonnes, if you want to be FIX compliant, then you have to attach the PtysSubGrp to a specific party and role to give it some context. You can identify the customer in PartyID(447) as I am assuming he is the owner of both accounts. Using PartyRole(452)=24 (Customer account) would mean that PartyID(447) contains an account number.
@hanno.klein, thanks for this feedback.
Actually, I want to put the “contract id” which is a container of both accounts (Securities and Cash) into the PartyID. At the moment, we send the “contract id” in the 1/Account field.
If it is more FIX compliant, we would continue using the 1/Account field and use 452/PartyRole=1.
Could you possibly suggest another value for the PartyRole?
@hanno.klein, looking into FIXimate, possibly 452/PartyRole=9 (Fund Manager Client ID) could do the job?
You can use any party and role as long as the subcomponents semantically belong to that party. A contract identifier did not sound like a party to me…
Next try:
453/NoPartyIDs=2
448/PartyID=<<contractId>>
447/PartyIDSource=D (Proprietary)
452/PartyRole=24 (Customer Account)
448/PartyID=CUSTOMER
447/PartyIDSource=D (Proprietary)
452/PartyRole=1 (Executing Firm)
802/NoPartySubIDs=2
523/PartySubID=<<account>>
803/PartySubIDType=10 (Securities account number)
523/PartySubID=<<liquidityAccount>>
803/PartySubIDType=15 (Cash account number)
Here I separated both concerns. The logical structure at our side is though:
<<contractId>>
|__<<account>>
|__<<liquidityAccount>>
Hope that looks more compliant.
Cheers, Jörg
@jorgthonnes, this forum is limited in terms of being able to support a comprehensive design that takes multiple business requirements into account. I can only point out the things to consider with regard to FIX compliance. PartyID(448)=“CUSTOMER” is not compliant as it does not identify a specific party but a category or type. This is what PartyRole(452) is for.
I also do not think that a contract qualifies as a party, but I do not know what this entity is about. Sounds more like a complex instrument. In this case, the InstrumentParties component would be a better place to convey account information related to the contract and would follow your logical structure. In the end, maybe using Account(1) and a user-defined field for the liquidity account is the best compromise and would be FIX compliant, e.g. SecondaryAccount(9550).
@hanno.klein, I found some other posts (Specify PartyRole(452)=3(Client ID) twice in NoPartyIDs(453)) with the same PartyRole used twice if they differ in the PartySubIDType. So an idea to convey the account numbers of the customer in a more compliant way could be:
453/NoPartyIDs=2
> 448/PartyID=<<account>>
> 447/PartyIDSource=D (Proprietary)
> 452/PartyRole=24 (Customer Account)
> 802/NoPartySubIDs=1
>> 803/PartySubIDType=22 (Securities account name)
> 448/PartyID=<<liquidityAccount>>
> 447/PartyIDSource=D (Proprietary)
> 452/PartyRole=24 (Customer Account)
> 802/NoPartySubIDs=1
>> 803/PartySubIDType=23 (Cash account name)
Irrespective of the business design I think this is FIX compliant.
Thanks, Jörg