OmniBus Architecture — Two ETNA Trader Instances

DOO FinancialRQD clearing Two ETNA Trader instances bridged by one inter-instance FIX session. Sub-accounts run with no clearing and are invisible to RQD; the Live Prod Omnibus instance (back.office.doofinancial.us) is the only clearing-facing book. Concrete IDs sit as mono chips under each node; unknowns stay TBD (violet).

Legend — flows & states
  • Internal operations
  • Inbound FIX (orders)
  • Outbound FIX (orders)
  • Execution reports / messages
  • Confirmed for DOO
  • TBD — not yet established
Sub-acct env Sub-Accounts Instance OMS / EMS No Clearing
env / URLTBD infra hostTBD statusnot yet provisioned
Clients / Traders
End Clients Web Trading App APIs · FIX / REST / WS
internal
Core Platform Components
Account / Order / Risk Mgmt Positions & PnL Reporting Back Office
internal
Sub-Accounts ServicesNo clearing
Instant Account Opening Funding — client-managed Internal Ledger / sub-account Corporate Actions — self Options Lifecycle — self Simplified Ops
Sub-Accounts Database per sub-account
ledgers
⛔ Invisible to RQD
Inter-instance
FIX session
Order → (FIX)
Exec reports ·
acks · fills · status · rejects
SenderCompIDTBD TargetCompIDTBD session nameTBD
Live Prod Omnibus / Fully Disclosed OMS / EMS Clearing Facing
Live Prod URLback.office.doofinancial.us infra hosthost.prod.live.df.projects.etna.etnasoft.com Demo Prod URLTBD
Back Office / Operations
Web BO Risk & Limits Reporting & Monitoring Admin Config
internal
Accounts on Omnibus Instance
Omnibus Accounts Fully Disclosed Accounts
👁 Both visible to clearing
internal
Core Platform Components
Account / Order / Risk Mgmt Positions & PnL Reporting
internal
Clearing & Execution Layer
Clearing Integration Settlement Custody Cash & Margin Compliance / Regulatory
→ Reports to clearing — RQD · positions / EOD / allocations
Omnibus Database consolidated positions /
cash / balances
Order-routing
FIX → Traffix
Validated
order →
← fills /
exec report
Clearing reporting →
positions · EOD · allocations
order MPIDTBD — DOFI? / DOOF? via gatewaysee venue path →
External Markets & Clearing
Infrastructure
Execution Venues — Exchanges / ECNs / ATS Market Makers / Liquidity Providers Clearing Firms — RQD Connectivity Providers
DOO venue path
Traffix = execution venue RQD reads trades from Traffix — no separate ETNA drop-copy QuoteMedia — market data (delayed) · Live + Demo Prod
FIX gatewayhost.prod.fixgateway.projects.etna.etnasoft.com route (PBI #229417)host.prod.live.df.projects.etna.etnasoft.com → host.prod.fixgateway.projects.etna.etnasoft.com order-routing MPIDTBD — DOFI? / DOOF? (await Bill)

Account opening — how it actually works

Master Omnibus account Visible to RQD

Opened as a corporate account on the clearing side.

Step 1Corporate account
→
Step 2RQD portal / PDF-in-Chrome workaround
no native ETNA form
→
TBDMethod: form / BO / API
pending RQD · Joe Sudia

Sub-accounts (under Omnibus) Invisible to RQD

ETNA owns the mechanic end-to-end — no clearing touchpoint.

Step 1Opened natively on our env
→
Step 2No form · no RQD touchpoint
→
FeedsT-008 Phase-1 form scope
confirmed

Order flow

1Client (sub-account) places order on the Sub-Accounts Instance.
2Order forwarded to the Omnibus Instance over FIX.
3Validated order routed to Execution Venue / Clearing over FIX.
4Fills / execution report flow back through Omnibus → Sub-Accounts → client.

Position aggregation

Sub #1AAPL 10
Sub #2GOOG 20
Sub #3AAPL 20
→
OmnibusAAPL 30
OmnibusGOOG 20

Omnibus is the clearing-visible net. Sub #1 buys TSLA 10 → routed through Omnibus; post-fill TSLA 10 added to both Omnibus and Sub #1.

Confirmed for DOO

Live Prod = back.office.doofinancial.us (ADO #228727) ETNA platform = OMS / EMS (both instances) Platform reports to clearing — RQD (positions / EOD / allocations) RQD = clearing Traffix = execution venue RQD reads trades from Traffix — no ETNA drop-copy (trade capture) QuoteMedia = market data (delayed) ACH + Wire day-1 (Check / ACAT out this phase) NVB precedent mirror Omnibus validations stripped — opposing sub-orders both fly; net can be zero Position lots track long-margin + short-lot separability Acceptance = end-to-end trading flow

Open questions — TBD

Pending RQD · Joe Sudia. Each item below is unconfirmed and blocks a part of the architecture above.

  1. FIX tags for sub-account identification — Tag1 / <Parties> PartyRole / custom 5000+; which PartyIDSource?
  2. Lot-level positions — does RQD expose long-margin & short lots (REST / SFTP)? Will RQD reflect sub-account positions from a daily allocation file (→ LOPR / CAT)?
  3. Pre-trade validations on Omnibus — buying-power, self-cross, EasyToBorrow-locate: RQD-side or ours?
  4. Multileg options — single combo under Omnibus vs legs decomposed per sub-account (NestedParties); offsetting cross-sub combos.
  5. EOD / SOD file granularity — Omnibus-aggregate only or sub-account level; inbound daily allocation file RQD wants.
  6. LOPR & CAT ownership — RQD files on DOO's behalf or DOO owns it.
  7. Omnibus open method (form / BO / API) + recommended Omnibus count per client (one like NVB, or several).