B2CONNECT expands account currencies and carries account identity through to liquidity providers

B2BROKER has detailed a B2CONNECT update covering margin-account currencies and account information passed to liquidity providers. Its public announcement is dated 23 October; the release notes are dated 30 September. The company documents these as released features.[1][2]

Account denomination becomes a configuration choice

Administrators choose a main asset from those enabled on their hub at account creation. Examples include EUR, GBP and JPY, alongside BTC, ETH and USDT. Balance, equity, margin, free margin and profit or loss use that asset, with instrument prices converted automatically. Funding and withdrawals use it too. USD remains the default, and existing accounts are unaffected.[1]

The practical change is a consistent accounting unit across funding and risk figures. A euro-funded account can show its margin requirement and equity in euros, making those figures easier to reconcile. Choosing that denomination does not itself change the underlying position or remove its currency exposure.[1]

Account labels reach the external execution leg

The release notes say B2CONNECT now carries the FIX Account field, Tag 1, through to the liquidity provider and back on the execution report. SenderSubID, Tag 50, and OnBehalfOfCompID, Tag 115, are included where enabled. Previously the provider received the taker’s accounts as an undifferentiated flow.[2]

This extends August’s support for multiple margin accounts on one FIX connector. That earlier change routed an incoming Account value to the correct internal margin account. September’s addition preserves attribution across the next boundary, from the hub to the external provider. Brokers can therefore distinguish sharing a connection from losing the identity of the account behind an order.[2]

The distinction is visible in the FIX interface itself. B2CONNECT’s API supports separate messages for a new order, an execution report and an order-cancellation request, using FIX 4.4. An order request is an instruction; the execution report communicates what happened to it. Keeping identifiers consistent across that exchange gives downstream systems a way to associate the result with the originating instruction, rather than treating every message arriving over the same connection as belonging to one account. The execution report distinguishes the current order state, OrdStatus, from the event being reported, ExecType, and includes the client’s order identifier.[3]

Recovery addresses a mismatch in order status

B2BROKER also reports a fix for a rare case in which a venue-filled order could be reported as expired after a liquidity provider closed its order-update stream. The platform now reconnects immediately and recovers the actual outcome, according to the release notes.[2]

Operationally, that is a reconciliation problem: a submitted order and a returned execution outcome describe different stages of the trade. If an application relies on a stale or incomplete outcome, it cannot safely infer the current position merely from the fact that the connection has returned. For a broker evaluating this workflow, the meaningful check is whether the recovered execution is associated with the correct original order and account, with the final state carried into its own records.[3]

Report an error or submit an update