Education
Contents
By Arizmic LLC8 min readPublished Last reviewed

Auction-profile strategies: value, migration, and acceptance

Use profile references as evolving auction context, not as self-executing support and resistance lines.

An auction profile shows where trading activity accumulated by price

An auction profile reorganizes market activity by price instead of only by time. A volume profile answers: how much volume traded at each price during a declared period?

The point of control, or POC, is the price bucket with the most measured activity. A value area is a convention that encloses a chosen share of profile activity around the concentration. High-volume nodes are relatively busy prices; low-volume nodes are relatively sparse.

These are descriptive references. “Value” here means an area of concentrated auction activity, not fundamental fair value. The POC is not automatically support, and a low-volume node is not automatically a target.

A strategy must define how price interacts with a profile built from information available before the decision.

What acceptance and rejection mean

If price moves outside a prior value area and continues to trade there, the new area may be gaining acceptance. If price moves outside and quickly returns, the excursion may be rejected.

Acceptance cannot be identified simply because price eventually continued. It needs an observable rule—time spent outside, volume accumulated, completed closes, or repeated transactions. Rejection likewise needs a defined excursion, return, and hold.

Migration describes a reference such as the POC moving over successive comparable profiles. A completed daily POC shifting higher for three sessions is not the same object as a current-session POC updating every minute.

Why profile locations might matter

Concentrated trading records areas where many transactions were completed. Participants may carry inventory and memory around those prices, and later trading may reveal whether the market still accepts them. Information, inventory, and the trading process provide a plausible framework for that hypothesis; they do not establish that a particular profile level will hold.

Sparse areas may be traversed quickly because less historical activity occurred there, but a profile does not reveal current resting liquidity or future intentions. Popular levels can attract orders without offering any directional edge.

The useful hypothesis is conditional: does a precisely defined interaction with a prior profile change the later outcome after execution and costs?

Profile construction is part of the model

ChoiceVariantsWhy it matters
Source periodPrior session, composite, rolling, event anchoredDefines the auction summarized
ActivityVolume-at-price or time-at-priceChanges what concentration means
Price bucketsTick, fixed width, adaptive groupingCan move nodes and POC
Value conventionDeclared percentage and expansion algorithmChanges the boundaries
Live/finalCompleted profile or updating partial profileDetermines when levels are known
EventAcceptance, rejection, migration, node traversalDefines the strategy hypothesis

Two software packages can produce different value boundaries from the same trades because their bucket and expansion conventions differ. Store those settings with the research.

An acceptance example

Illustrative example. Assume yesterday’s completed profile has:

  • value-area low: 99;
  • POC: 101; and
  • value-area high: 103.

Today opens inside value and later trades above 103. An illustrative acceptance rule declares:

  1. The prior profile remains fixed for the full session.
  2. Price must complete three consecutive five-minute closes above 103.
  3. Volume accumulated above 103 during that interval must exceed a predeclared same-time baseline.
  4. Enter long at the next modeled event.
  5. Invalidate on a completed return inside prior value or at the session time limit.

The three closes and activity threshold are known only after the confirmation interval. The strategy cannot claim a 103 entry unless a separate resting-order model was already in force.

A rejection rule asks the opposite question and should be a separate variant: price trades beyond 103, returns inside, and remains there under a declared condition.

Designing the comparison

Start with a price-only interaction with the prior value boundary. Then add acceptance or rejection criteria while keeping the entry timing, risk, and costs comparable.

Report:

  • every boundary interaction;
  • confirmed and rejected counts;
  • time and distance consumed by confirmation;
  • performance by prior profile width and opening location;
  • sensitivity to bucket and value-area conventions;
  • outcomes using completed versus partial profiles; and
  • cost and slippage near popular references.

For migration, compare profiles built over identical windows. A rising partial session POC may merely follow the day’s accumulating volume and should not be compared directly with a completed prior session.

What makes profile evidence fragile

Profile levels can look precise because they are drawn as exact prices. That precision is partly an artifact of bucket size and source data. Thin markets can produce unstable nodes, while aggregated bars cannot reconstruct true volume-at-price without assumptions.

The conclusion is weak when the profile convention was chosen after inspecting results, when current-session levels are treated as final early in the session, or when later price action is used to label acceptance.

Important failure modes

  • Different algorithms place POC and value boundaries at different prices.
  • Partial profiles move as new trades arrive.
  • Sparse data creates unstable nodes with little supporting activity.
  • Aggregated bars approximate rather than observe volume-at-price.
  • A popular reference attracts activity but has no directional implication.
  • Confirmation consumes most of the move before a tradable decision.

Try it in Arizmic

Strategy composition

Build the premise with shipped signals

Use profile levels as measured references, then define a behavior around them: acceptance, rejection, migration, or confluence. A POC or value-area boundary is not an entry by itself.

These are starting structures, not presets or evidence of an edge. Choose one, replace the bracketed decisions, and keep the signal roles separate as you test it.

Composition 01

Value-area acceptance with POC migration

Acceptance recipe
  • Session POC, VAH, VALAuction references
  • Value-Area Acceptance/RejectionBehavioral state
  • POC Migration VelocityValue migration

Data: Tick Replay, OHLCV Bars

View configuration and complete rule

Session POC, VAH, VAL

Auction references

Session Profile Levels supplies the current point of control and value-area boundaries.

Configure

No configurable parameter is required for this role.

Use the output

poc
Retain the current accepted-value center.
vah
Use the upper value-area boundary in the declared acceptance/rejection rule.
val
Use the lower value-area boundary in the declared acceptance/rejection rule.

Value-Area Acceptance/Rejection

Behavioral state

Value-Area Acceptance/Rejection distinguishes sustained trade inside or outside the current value area.

Configure

hold_bars · [acceptance bars]
Define how long price must hold before the state qualifies.

Use the output

accepted
Use the declared accepted state as eligibility or continuation confirmation.
rejected
Use rejection as the opposite behavior, not as a synonym for acceptance failure.
value_area_state
Retain the full state for transition analysis.

POC Migration Velocity

Value migration

POC Migration Velocity shows whether the accepted-value center is moving with or against price.

Configure

lookback · [migration lookback]
Set the interval over which POC movement is assessed.

Use the output

poc_velocity
Require [direction/magnitude policy] or use it to separate static from migrating value.

Assemble the rule

Entry
Enter only after the declared value-area acceptance or rejection state and POC-migration policy are known.
Exit
Exit on opposite value-area state, POC migration reversal, fixed risk rule, target, or session cutoff.
Decision time
Profile levels and hold-bars must be available through the completed decision bar; do not backdate acceptance to the first boundary touch.
Sizing
Use [price/ATR risk] with a session cap; profile distance alone is not a risk model.

Useful variations

  • Compare acceptance continuation with rejection reversion as separate rules.
  • Vary hold_bars separately from the POC-migration lookback.
  • Freeze profile references at entry versus use live migrating references for a clearly labeled exit variant.

Keep in view

Profile levels evolve as more volume trades. A live reference can move toward price, so apparent convergence may reflect profile migration rather than price returning to accepted value.

Composition 02

Profile-node reaction with prior-POC confluence

Confluence recipe
  • HVN/LVN ProximityCurrent node location
  • Prior-Session POC ConfluencePrior-session reference
  • Trend RegimeContinuation/reversion policy

Data: OHLCV Bars, Tick Replay

View configuration and complete rule

HVN/LVN Proximity

Current node location

HVN/LVN Proximity measures distance to current high- and low-volume nodes and flags nearby states.

Configure

tolerance · [node tolerance]
Define how close price must be to a node in the product’s declared units.

Use the output

near_hvn
Label candidate reactions near a high-volume node.
near_lvn
Label candidate reactions near a low-volume node.
distance_to_hvn
Retain exact distance for sensitivity.
distance_to_lvn
Retain exact distance for sensitivity.

Prior-Session POC Confluence

Prior-session reference

Prior-Session POC Confluence identifies when current price is also near the prior session’s accepted-value center.

Configure

tolerance · [prior-POC tolerance]
Set confluence independently from current-node proximity.

Use the output

in_confluence
Require a true confluence state or compare it as a label.
poc_distance
Retain the exact distance to prior POC.

Trend Regime

Continuation/reversion policy

Trend Regime helps specify whether the same node reaction is treated as trend continuation, fade, or no-trade.

Configure

adx_threshold · [strength threshold]
Define directional eligibility.
slope_threshold · [slope threshold]
Define minimum trend slope.
spread_threshold · [spread threshold]
Define minimum trend separation.

Use the output

trend_regime
Apply [continuation, reversion, or exclusion] policy by state.

Assemble the rule

Entry
Apply [declared price reaction] only when node proximity, prior-POC confluence, and the chosen trend-state policy align.
Exit
Exit when price leaves the node under [rule], reaches [next profile reference], invalidates, or times out.
Decision time
All profile references and the price-reaction event must be known at the completed decision bar.
Sizing
Use [separate price/volatility risk] and cap exposure in thin LVN regions.

Useful variations

  • Compare HVN and LVN reactions rather than pooling them.
  • Remove prior-POC confluence to measure incremental selectivity.
  • Treat trend regime as a label first, then as a gate.

Keep in view

HVNs, LVNs, and POC depend on profile scope, binning, and data fidelity. A result that disappears under nearby construction settings is not robust auction evidence.

Ask the AI Companion

Draft this strategy

Strategy draft

Turn an auction-profile idea into a simple draft and explain how value, acceptance, rejection, and migration differ.

I want to create an auction-profile strategy for [instrument and session] using trading activity from [prior session or other declared profile period]. Recommend how the profile should be constructed, which timeframe to begin with, and whether acceptance, rejection, migration, or a return toward value is the most suitable starting behavior. Then build the strategy for me and explain when its profile references are fixed, when they may update, and what would invalidate the chosen interpretation.

Extend it in Marimo

Study review

Begin from a retained profile-aware Study so construction settings and evolving references remain traceable.

Separate price movement from profile-reference movement around acceptance, rejection, and migration events.

Bring in
engine-reported POC, VAH, VAL, acceptance, node, confluence, regime, decisions, and fills, profile scope, binning, session, and data-fidelity settings, retained candidates, costs, and outcomes
Build
price-and-profile evolution chart with original decision markers, price-change versus reference-migration decomposition, event outcome and sensitivity table by profile construction and state

Interpretation: Check whether the claimed behavior survives nearby profile settings and whether the reference used at decision time was available before the trade.

Value origin: Profile features, signal outputs, decisions, fills, and retained metrics are engine-reported. Migration decompositions, matched events, and construction-sensitivity summaries are notebook-derived.

With Companion: Ask Companion to draft reviewed profile-evolution cells, inspect reference timing and construction metadata, then explicitly apply the diff.

Further reading