Imported from previous forum
Alas nested repeating groups are anathema in SBE since we lose direct access. This kind of verbosity is more suited for FIXML. The approach using PartyRoleQualifier seems to be very convoluted, so in essence we would have something like this to represent give-up (ABC) and take-up (DEF) account?
PartyID=ABC
PartyIDSource=C
PartyRole=24 (customer account)
PartyRoleQualifier=18 (current)
PartyID=DEF
PartyIDSource=C
PartyRole=24 (customer account)
PartyRoleQualifier=19 (new)
If so then this is confusing and is not clear or self-explanatory at all.
Just wanted to clarify the usage for the new party roles added in EP118 for give-up and take-up. If the order is being marked for give-up pre-execution then would the trading firm whom it is being given-up to be designated as 95=Give-up (trading) firm party role? This is assuming that the trading firm placing the order is designated as 7=Entering Firm.
No, the firm giving up one of their trades is called the Give-Up firm. The firm whom a trade is being given up to is the Take-Up Firm. This party receives the trade to then confirms the take-up from his point of view.
The trading firm placing the order should be 1=Executing Firm. Only if somebody else, e.g. a service provider is doing so on behalf of this firm you would additionally need 7=Entering Firm. Normally the firm having the business responsibility (=executing) is also the one using the GUI or API (=entering).
Have a look at the usage examples in the proposed workflows (Chapter 4) in EP118.
Thanks, this is interesting, based on some other work that we have done with other venues this is the description we have for entering versus executing:
• Trader (or entering trader): Individual usually identified by the trading badge number or initials that actually enters an order to a market (operator). Usually the entering trader is the same as the executing trader. However, under some circumstances the entering trader will have the trade executed by another trader who is then identified as the executing trader.
That looks fine to me. The one actually entering is taken as the one also executing it unless he enters a different information about the executing trader. Thereby he hands off the business responsibility to this other trader. This is at the time of order entry. You can also have the case that ownership of the order changes through order modification. That is part of the latest Gap Analysis I submitted to the GTC very recently (order handling extensions). You can never change the entering trader as it is always the one “entering” the request. But you can define a different executing trader.
Okay so entering firm=ABC is submitting orders for itself and if it asks firm DEF to submit its orders then executing firm=DEF and entering firm=ABC.
Likewise if firm ABC wants to give-up the trade to DEF then entering firm=ABC and give-up firm=ABC and take-up firm=DEF.
No, if ABC asks firm DEF to submit its orders then executing firm=ABC and entering firm=DEF. The submitting firm is always the entering role and either does it of himself (executing firm is then the same) or for somebody else (different executing firm).
Yes, if firm ABC wants to give-up the trade to DEF then entering firm=ABC and give-up firm=ABC and take-up firm=DEF.
Thanks, I also noticed that there is no party role for take up account which could belong to the executing firm or could belong to the take up trading firm.
That depends on your rules®s as well as workflows. Eurex does not require the giveup firm to have knowledge about the account of the takeup firm and also believes the choice of account should be at the discretion of the takeup firm. Eurex obtains the account information from the takeup firm when it confirms the takeup.
You can alternatively use PtySubGrp for the takeup firm with your own PartySubIDType(803) values if none of the existing ones for account information suits you. The account is then linked to the takeup firm by being nested. I do not think we need additional party roles for giveup/takeup accounts.
Yet another option is to use the new PartyRoleQualifier(2376) values Current(18) and New(19) added with EP213. You would use one of the account party roles and qualify it to provide the new account information.