Blog · Wallet share and penetration · Trading

Size-weighted hit ratio: why the count-weighted number hides the losses

Why a trading desk's hit ratio should be weighted by ticket size as well as counted, how the two diverge when a competitor commits balance sheet, the computation from the RFQ log, and a worked example where a rising count-weighted ratio masks a falling share of volume.

By CoviragePublished 16 September 20263 min read

The short answerCount-weighted hit ratio is requests won divided by requests received. Size-weighted hit ratio is notional won divided by notional received. When the two diverge, the desk is winning the small tickets and losing the large ones, which is what happens when a competitor commits balance sheet to a client. Compute both from the RFQ log, per client and product, and read the gap between them as the signal.

A desk head sees hit ratio rise from 30 to 34 percent on a client and reads it as good news. The same quarter, the desk's share of the client's volume fell from 32 to 21 percent. Both are true. The desk is winning more of the small tickets and losing the large ones to a competitor who has committed balance sheet to the client. Count-weighted hit ratio cannot show that. Size-weighted can. This guide sets out both and how to read the gap.

The two ratios

Per client, product and window:

Count-weighted = requests won ÷ requests received Size-weighted = notional won ÷ notional received

When they agree, the desk wins the same share at every size. When count exceeds size, the desk is losing large tickets. When size exceeds count, the desk is winning them and losing the small ones, which is rarer and usually a pricing tier problem.

The rows you need

RFQ log: client, product, size, received flag, quoted flag, won flag, timestamp.
Blotter: executed trades with size, to reconcile the won side.
Coverage: sales-trader per client.

Client identifiers only.

The computation

Per request: won or not, size.
Per client and product: count received, count won, notional received, notional won. Both ratios.
By size bucket: split requests into buckets by the client's own size distribution, and compute both ratios per bucket.
Assert: notional won by client sums to the blotter, and requests without a size are counted.

blotter notional = Σ clients (notional won)

A worked example

One client, swaps, this quarter against last.

Bucket	Requests	Won	Count ratio	Notional received	Notional won	Size ratio
Small, under 25m	280	112	40%	3.1bn	1.2bn	39%
Medium, 25 to 100m	96	28	29%	5.2bn	1.5bn	29%
Large, over 100m	36	4	11%	6.8bn	0.7bn	10%
All	412	144	35%	15.1bn	3.4bn	23%

Last quarter the large bucket was at 30 percent. Count-weighted hit ratio rose from 32 to 35 percent because the small bucket grew. Size-weighted fell from 31 to 23 percent because the large bucket collapsed. The desk head's number went up while the desk lost a third of the client's flow.

Reading the gap

Count minus size	Reading
Near zero	Winning evenly across sizes
Count higher by 5 points or more	Losing large tickets; balance sheet or pricing at size
Size higher by 5 points or more	Losing small tickets; pricing tier or response time on small requests

The gap per client, tracked quarter on quarter, is the earliest desk-level signal that a competitor has changed its posture on an account.

Where it goes wrong

Sizes missing on requests. Requests logged without a notional are excluded from the size ratio and the count ratio looks complete. Count the sizeless requests and get the field populated.

Units mixed. Notional in one venue's export and contracts in another. Convert before summing.

Buckets fixed globally. A client whose typical ticket is 200m has no small bucket. Set buckets per client from its own history.

Declines dropped. A request the desk declined to quote still counts as received. Otherwise both ratios flatter the desk.

Every quarter, per client

Mapped once, the RFQ log produces both ratios per client, product and bucket every quarter, with the gap and its trend, reconciled to the blotter. Covirage builds this inside the bank's tenant on an enterprise deployment. The trading page describes the setup, and the hit ratio guide covers the count-weighted version and the three drifts.

Questions people ask

Which one should the desk report?

Both, side by side, per client and product. Either alone can be misleading in a specific and predictable way. The gap between them is the number that says what kind of competition the desk is facing.

What sizes count as large?

The desk's own distribution sets it. Split each client's requests into size buckets by the client's own history, and compute hit ratio per bucket. The largest bucket is where balance sheet competition shows first.

Does this need the blotter?

The RFQ log gives both ratios if it records size on every request. The blotter reconciles the won side and catches requests logged without a size.

Related reading

Coverage and territory · Trading

Axe distribution: which clients receive the desk's axes, and which ones trade them

How a trading desk measures whether its axes reach the clients who trade them, from the axe log, the distribution records and the blotter: axes sent per client per product, axes traded within a stated window, the clients who receive many and trade none, the clients who trade the desk's axes but receive few, the salespeople whose distribution lists have not changed in a year, and the identity that trades against axes sit inside the blotter.

16 Sept 20262 min read Territory, capacity and quota planning · Trading

Client tiering by flow and hit ratio: where the desk should spend its axe

How a trading desk tiers its clients from the RFQ log and the blotter rather than from the coverage list: two axes, notional traded and hit ratio, four tiers that follow, the clients with high inquiry volume and low hit ratio who consume pricing effort for little, the clients with high hit ratio and modest flow who would trade more if shown more, and the quarterly re-tiering that moves clients on their own numbers.

16 Sept 20262 min read Wallet share and penetration · Trading

Hit ratio by client and product: a trading desk's guide to flow share

How a sell-side desk computes hit ratio and flow share per client and product from its own RFQ logs and blotter, why the two numbers must be read together, and the three drifts that predict a client is leaving before the revenue shows it.

16 Sept 20264 min read Coverage and territory · Trading

Ten questions a head of sales trading asks, and the table that answers each

The ten questions a head of sales trading puts to the salespeople and the traders, which clients have gone quiet in a product where the desk has not, what is the size-weighted hit ratio by client, which clients are tiered where by flow and hit ratio, which axes reached the clients who trade them, who is covered by one salesperson only, what does the coverage map look like by client and product, does the blotter reconcile to the benchmark submission, which clients receive many prices and trade none, which salespeople's distribution lists are stale, and what changed, each with the table from the RFQ log, the blotter and the coverage file, and the answer to send back.

16 Sept 20262 min read