I asked the same question earlier.
Jed mentioned that trades are applied in random (actually, pseudo-random) order, and transaction fees do not affect the order in which transactions are applied within the ledger. So larger fees do not prioritize trading operations, preventing Low Latency HFT manipulations.
(Detailed explanation of the tx randomization process)
First the transaction set is reordered in apply order: during consensus, the transaction set was sorted by hash to keep things simple, but when it comes to actually applying them, they need to be sorted such that transactions for a given account are applied in sequence number order and also randomized enough so that it becomes unfeasible to submit a transaction and guarantee that it will be executed before or after another transaction in the set. See
TxSetFrame::sortForApply for more detail.
Therefore once the SCP quorum agreed on what transactions are ready for the application in the current frame, all transactions are first ordered by the sequence numbers (to prevent applying transactions in the wrong order), and then randomized based of the seed derived from the hash of the particular transaction XORed with the hash of the entire tx set (see
One can predict the transactions application order only if she knows in advance the contents (or at least hashes) of all submitted transactions. While it is theoretically possible to monitor all transactions (in the simplest case the attacker may submit all transactions by himself), the information is effectively useless, as any new transaction submitted after the transactions frame was assembled, will be included into the next ledger. However, the tx application order and current ledger state will be publicly available only a few seconds later anyway, so the attacker has no competitive advantage in this case.