The Percent of Volume (POV) algorithm - also called volume participation - abandons the fixed timetable entirely. Instead of “finish by 4pm,” the instruction is “be X% of the market until done.” Where TWAP follows the clock and VWAP follows volume history, POV follows the tape: its schedule is drawn in real time by the volume that actually prints.

How It Works

The trader specifies a target participation rate - say 12% - and the algorithm continuously issues orders so that its executed quantity stays at that fraction of total market volume.

• Direct aggression control. This rate represents the algorithm's aggression. The higher percent of volume this is set to, the more aggressive. 5% is stealthy; 30% is loud. No other mainstream algorithm gives the trader such an interpretable knob.

• A schedule that draws itself. There is no precomputed curve. Quiet trading periods add little to the target schedule; volume bursts pull the target up sharply. Two identical orders on two different days will trace completely different execution paths.

• Tracking bands. As with the scheduled algorithms, implementations allow drift within a tolerance around the target rate - using passive orders inside the band and marketable orders at its edge.

• No guaranteed end time. The completion time is an output, not an input. If the market goes dead, so does the order - a feature when impact matters most, a bug when a deadline exists.

• Launch behavior depends on configuration: an algorithm allowed to run ahead of target may post a working quantity immediately, while one capped strictly at the target must wait for market volume to print before its first order.

An Example

Take a 15% participation target. For the algorithm to be 15% of the total after it trades, it fires roughly 176 units for every 1,000 units of external volume - because after its own fill the total becomes 1,176, of which 176 is almost exactly 15%. This “gross-up” arithmetic is a classic implementation detail: naive versions that fire 150 per 1,000 systematically undershoot, since their own prints inflate the denominator.

Scale it up: on a 40,000-unit order at 15%, a session that trades 120,000 units externally moves the order about 21,200 units; a dead session barely moves it at all. When a single block of 20,000 crosses the tape, the target jumps by ~3,500 immediately - the algorithm accelerates exactly when liquidity appears.

Why Traders Reach for POV

POV is VWAP’s logic applied in real time. VWAP trades where volume usually is; POV trades where volume actually is right now. That distinction carries a subtle risk benefit: market volume and market risk are positively correlated - volatile periods are high-volume periods - so a POV order automatically speeds up precisely when staying exposed is most dangerous. The algorithm de-risks itself in storms without being told to.

Design Pitfalls

Three traps every POV implementation must handle:

• The self-chasing loop. If the algorithm measures participation against total volume including its own fills naively, its trades raise the volume count, which raises the target, which triggers more trades. Correct implementations either measure against external volume or apply the gross-up arithmetic described above deliberately.

• Print filtering. Not all reported volume is accessible liquidity. Block trades negotiated off-book, auction prints, and - in crypto - inflated or wash-prone volume on loosely surveilled venues can all jack the target upward when no real liquidity is available. Production algorithms filter which prints count toward the denominator.

• Clip discipline. Chasing the target with a flurry of tiny orders after every print leaks information. Better implementations accumulate an execution deficit and release it in randomized clips, blending the same anti-gaming toolkit described in Part 4.

Where POV Fits

POV work best in markets where impact control matters more than completion certainty: sensitive names, wide-spread instruments, episodic-liquidity assets - and any situation where “don’t be more than X% of the tape” is itself the mandate (a common compliance constraint). Its blind spots are the deadline problem and its purely reactive nature: it needs volume to have printed before it acts, so it is always slightly late to a liquidity event.

The natural next step fixes that reactivity: an algorithm that lies in wait and pounces on liquidity the moment it appears. That is the opportunistic family - Part 7: Hide and Take.