Skip to main content

Broker-fee reconciliation

Per-trade cross-check of the MODELED broker cost (what the ledger booked to ViewTrade Payable) against the CONFIGURED assumption and the ACTUAL fees on ViewTrade's Daily Ledger.

The three references​

ReferenceWhere it comes from
ModeledWhat the recost actually booked to ViewTrade Payable
ExpectedConfigured cost-bps × trade notional (the assumption)
ActualSum of itemized broker fees on the Daily Ledger's TRD row

The drift signal comes from comparing them.

What the report tends to surface​

The flat 4-bps cost assumption doesn't survive small-ticket fractional trades. ViewTrade has fixed per-trade fees (SEC, TAF, IFSCA, others) that dominate at small notionals. A $10 trade might have $0.02 of fixed fees — 200 bps — even though the assumption is 4.

The report exposes this per trade and firm-wide. Every trade that drifts more than 1 cent is flagged.

What it means for the business​

  • Modeled > actual → the ledger is over-booking to ViewTrade Payable. Valura owes ViewTrade less than the ledger says, so when the monthly ViewTrade statement lands the settlement is smaller. Under-books Valura's own margin.
  • Modeled < actual → the ledger is under-booking. Valura owes ViewTrade more than the ledger says. Cash-flow surprise at settlement.
  • Persistent drift → the fee schedule assumption is inadequate for the book's actual trade mix. Consider a piecewise fee schedule (fixed per-trade + variable bps).

Where to see it​

  • Frontend: the Broker-fee card on /ops-audit (India book). Actuals badge shows the Daily-Ledger match rate.
  • API: GET /v1/india/broker-fees.

Follow-ups​

  • Wire ViewTrade's orders/preview endpoint at ingest to capture actual fees on every trade — removes the Daily-Ledger match-rate uncertainty.
  • Move to a piecewise cost schedule.