FIX Trading

FIX is an open industry standard for online trading.

The FIX protocol is widely used to automate trading. It defines protocols and message formats that can be used instead of the panic-mode phone calls and hand signals that were common on older stock exchanges.

FIX avoids mistakes, it automates mundane tasks and that means that it saves on expenses. FIX is also the langauge spoken with respect to an exchange. An exchange is, roughtly said, a queue of purchase orders and a queue of sale orders which will be paired when they match. FIX handles the input and output of this process, but it also guides negotiations between parties before and after the queue their trades, such as exchange of quotes and payment information.

Adding SASL

Normally, FIX uses username/password login. That is fit for a closed system, but we anticipate open markets where anyone can authenticate, and where it is up to Access Control to optionally constrain rights. This is possible with our Realm Crossover technology.

SASL authentication is a mechanism to get to this point. It will be defined at the start of the FIX protocol exchange, with support for Realm Crossover, so anyone with a domain supporting such identity verifications can access the exchange. We further use the ARPA2 mechanisms for Identity and Access, which means that Groups may be assigned rights.

Adding or removing Group Members is a straightforward local operation, and does not involve the exchange. This means that a high degree of control is granted to the customer using the exchange, and to their local account managment.

SASL has straightforward simple requirements, and FIX can easily accommodate that. We shall define User Defined tags for this purpose.

More: Technical Specification

Static Pricing

Normally, an exchange pairs buy and sell orders on their pricing. But for Taler Bullion currencies, the pricing is fixed! That is the result of the direct relation to the coin and its underlying value. The thing that may differ is how the currency is expressed; for instance, an hour of human attention spent on editing your text may be used, or two grams of gold for sending me flowers could be used. But the thing that we do with FIX is not related to such content; it is about swapping Taler Bullion for the title of ownership on the underlying value. And that always happens at a 1:1 ratio or otherwise at a static rate that might be based on (say) the usability of the underlying value, such as the purity or net gold weight of a gold bar.

The most important thing that an exchange needs to do is making atomic decisions on what value is coupled to what Taler Bullion currency. In case of bulk orders, this may not always be pair one buy order to one sell order, but it could be that one bulk order is matched with many smaller ones or that bulk orders are partially matched.

Seeing that prices or fixed, there can be other considerations, such as fairness in trading. One way of doing this is first-come-first-served, but that may give rise to pounding hearts and stressed arteries. This is not always necessary. For instance, trades in energy during a time slot might be collected for the duration of a time slot, and finished afterwards. The same might be done with gold trades. It may be considered more fair to spread the available trades equally over parties. The function of queueing trades is not at all uncommon to an exchange, so this is just another implementation strategy that could be used.

FIX Messaging: Pre-Trade

See the trade specification and its messages & components.

We support information exchange on available transactions for securities (underlying values) but not its derivatives, or on parties.

Category Indication:

• Advertisement is sent to make a potential transaction known (and later to make it unknown). TODO: Useful?
• CrossRequest(Ack) are Not Implemented.
• IOI is sent as an Indication Of Interest to respond to an Advertisement.

Category Event Communication is probably useful to implement:

• News is messaging to multiple recipients, for instance all traders on a market.
• Email is messaging between parties, usually two market traders.

Category Quotation / Negotiation is Not Implemented. The exchange rates in Taler Bullion are fixed.

Category Market Data is Not Implemented. There does not seem to be a purpose for it.

Category Market Structure Reference Data is Not Implemented. There does not seem to be a purpose for it.

Category Securities Reference Data:

• DerivativeSecurityList(Request) is Not Implemented. Taler Bullion is intended to deal in fully value-backed currencies and does not support derivatives.
• SecurityDefinition is to relay information on a security/value to be swapped for Taler Bullion currency, and on its acceptability.
• SecurityDefinitionUpdateReport is Not Implemented because we aim for stable and static value backing. Securities may be retracted, that's it.
• SecurityListRequest can be sent to request a list of available securities in the exchange.
• SecurityList is sent from the exchange, either upon request or spontaneously, to convey available securities.
• SecurityListUpdateReport is Not Implemented.
• SecurityMassStatus(Request) is Not Implemented.
• SecurityStatus(Request) is Not Implemented because we want static securities/values.
• SecurityType(Request) is used to see what another party has on offer.

Category Parties Reference Data is Not Implemented.

Category Parties Action is Not Implemented.

FIX Messaging: Trade

See the trade specification and its messages & components.

We support basic orders and getting them executed.

Category Single/General Order Handling:

• NewOrderSingle is sent from a trader to the exchange
• ExecutionReport is sent back by the exchange
• ExecutionReportAcknowledge is normally sent as a positive confirmation after receiving an ExecutionReport
• DontKnowTrade is sent when an invalid ExecutionReport was received (which would normally be a sign of software malfunction)
• OrderCancelReplaceRequest is sent from a trader to the exchange, to update an outstanding order without fully cancelling it. Not Implemented.
• OrderCancelRequest is sent to stop further processing of an order.
• OrderCancelReject is the response of the exchange to an OrderCancel(Replace)Request which is no longer possible. This is different from the accepting response, which produces an ExecutionReport.
• OrderStatusRequest can be used to explicitly request an ExecutionReport from the exchange.

Category Mass Order Handling is not implemented. For now, we shrug off this added complexity.

Category Cross Order Handling is not implemented. It is mostly used for intermediates who pair requests from their local customars at market-conforming prices.

Category Multileg Order Handling is not implemented. We deal with simple trades.

Category List/Program/Basket Trading is not implemented. This is a concept for stock market exchanges, under fluctuating prices. We do not need that for the static exchange rates in Taler Bullion.

FIX Messaging: Post-Trade

See the trade specification and its messages & components.

We support information about the movement of the Taler Bullion currency payment and the underlying change in ownership (and possibly physical movement) of the underlying value of a trade.

Category Allocation is Not Implemented. We have no use for managing portfolios because Taler Bullion has static exchange rates.

Category Confirmation:

• ConfirmationRequest may be sent from buyer to seller to request a Confirmation.
• Confirmation conveys information on a trade befor it is settled, from seller to buyer.
• ConfirmationAck affirms or rejects the Confirmation and is sent from buyer to seller.

Category Settlement may or may Not be Implemented:

• SettlementInstructionRequest requests settlement instructions. Do we need it?
• SettlementInstructions inform about settlement. Do we need it?
• SettlementObligationReport instructs a currency settlement from a central counterparty. Do we need it?

Category Trade Capture Reporting is Not Implemented. Or do we need it? Perhaps for auditing of accounts?

Category Registration Instruction is Not Implemented.

Category Position Maintenance may be useful:

• AssignmentReport may be used to report on the settlement by booking Taler from a wallet to a merchant account.
• [ContraryIntentionReport](https://www.fixtrading.org/online-specification/post-trade-appendix#msg094-1) is Not Implemented.
• Position* is Not Implemented.

Category Collateral Management is Not Implemented.

Category Margin Requirement Management is Not Implemented.

Category Account Reporting:

• AccountSummaryReport may be used to report on Taler clearance of a security trade.

Category Trade Management is Not Implemented.

Category Pay Management is Not Implemented, if Taler settlement is commenced by the exchange.

Category Settlement Status Management:

• SettlementStatus(Request|Report)(Ack) may be useful to be informed about a movement of securities.