- Do not use “optimizer,” “trader” and “aggregator” as synonyms; ask what regulated, commercial and operational function is actually performed.
- Market access, imbalance responsibility and physical control can sit with different parties and require a reconciled data/command chain.
- The contract should say who decides, who approves, who executes, who pays and who is liable when delivery differs.
Define the roles by responsibility
| Role | Core function | Does it necessarily control the asset? |
|---|---|---|
| Asset owner | Owns the BESS and its investment, warranty and operating obligations. | Retains ultimate rights but may delegate bounded dispatch. |
| Optimizer | Calculates bids, schedules, reserve allocation or dispatch targets. | No; it may provide advice or sit in an automated chain. |
| Trader | Submits orders and manages market positions through the relevant venue/access. | No; a separate system may translate trades into dispatch. |
| Aggregator | Combines multiple resources or customers for market/system participation. | May dispatch the portfolio under contract, but local controls remain. |
| BRP | Is responsible for attributed imbalances under the applicable framework. | No; needs data and influence sufficient to manage exposure. |
| BSP | Provides qualified balancing capacity and/or energy to the TSO. | Requires a reliable activation-to-delivery path. |
| EMS / edge | Coordinates and executes authorized plant targets within local constraints. | Yes, at the bounded plant-control layer. |
EU Regulation 2017/2195 formally defines BRP, BSP, balancing capacity, balancing energy and imbalance. “Optimizer” is primarily a commercial/technical function rather than one harmonized regulatory role. “Aggregator” may be defined and regulated through EU and national frameworks, with implementation differing by country.
Common operating structures
Owner + trader/BRP + optimizer
The owner contracts market access and imbalance responsibility, while an optimizer provides positions or schedules. The owner or site operator retains physical dispatch approval. This separates expertise but needs fast reconciliation between trade and plant.
Integrated optimizer-trader
One counterparty forecasts, optimizes and trades. It may reduce handoffs and align incentives, but the owner should still understand benchmark, fees, conflicts, data rights and control authority.
Aggregator portfolio
An aggregator combines assets to reach product thresholds, diversify errors or offer portfolio flexibility. The individual BESS must still deliver its assigned share and report availability. Portfolio-level optimization should not ignore site limits.
Tolling
A toller may receive defined dispatch rights and market economics in exchange for contracted payment. The asset remains inside warranty, grid and safety constraints. See the tolling vs merchant guide.
How the roles interact during one interval
The optimizer should ingest actual positions rather than assume its recommendation was traded. The dispatch layer should receive an authorized, versioned net target rather than infer it from price. The BRP needs delivered measurements and trade changes. Every handoff needs time, identity, status and ownership.
Build a responsibility matrix before signing
- Who owns day-ahead, intraday and balancing forecasts?
- Who submits, changes and cancels orders?
- Who posts collateral and carries failed-trade or liquidity risk?
- Who is BRP/PRE and who pays residual imbalance?
- Who determines target SOC, reserve headroom and cycle budget?
- Who may write the site active-power target?
- Who validates BMS, PCS and point-of-connection limits?
- Who monitors delivery and responds outside business hours?
- Who owns data, models, settlement records and audit trails?
- How are performance fees benchmarked and disputes resolved?
Express performance against a controllable baseline. A trader should not be rewarded for market price movement it did not cause; an optimizer should not be penalized for unavailable power it was not told about. But unreported availability is itself an interface failure that needs ownership.
How to select a route-to-market partner
Request a same-data backtest with frozen forecast vintages, executable market assumptions and the project’s constraints. Ask for gross-to-net reconciliation and poor-period results. Then test operational readiness: APIs, position updates, 15-minute scheduling, command acknowledgement, on-call support, incident handling and exit.
Review incentives. A fixed fee, revenue share, floor or toll changes who benefits from volume, volatility and asset preservation. Make degradation budget and opportunity cost visible. Require the proposed optimizer to explain how reserve commitments and energy trades share SOC.
Country rules decide the formal arrangement
Bulgaria’s ESO registers, Romania’s PRE/Transelectrica framework and Greece’s IPTO storage-entity process are not interchangeable. Market access can require different licenses, agreements, representation, registration, prequalification and metering. Use the country guides for Bulgaria, Romania and Greece, then verify the current primary documents.
VoltMage can provide forecasting, optimization, policy and edge components while working with an existing trader, aggregator, BRP or EMS. The integration starts by defining roles—not by assuming VoltMage must replace them.
Where incentives commonly become misaligned
A revenue-share optimizer may be encouraged to increase gross trading revenue while the owner pays degradation and auxiliary energy. A BRP may prioritize portfolio imbalance reduction over one battery’s merchant opportunity. An aggregator may value reliable reserve capacity more than day-ahead spread. An EMS vendor may optimize local availability but know nothing about market positions.
Resolve this with a net-revenue definition and constraint governance. State which costs enter the performance calculation, who approves changes to the cycle budget, and how foregone value is treated when one service blocks another. Use symmetric treatment of upside and downside and an independent source for market settlement where possible.
Example RACI for an intraday correction
| Action | Responsible | Accountable / informed |
|---|---|---|
| Update PV/price forecast | Forecast provider | Optimizer and trader informed |
| Calculate revised position | Optimizer | Owner strategy accountable |
| Place and confirm order | Trader | BRP and optimizer informed of fills |
| Issue net site target | Authorized dispatcher | EMS/operator accountable |
| Enforce limits | EMS, PCS and BMS | Operator and optimizer informed |
| Reconcile settlement | BRP/settlement function | Owner and service providers informed |
The actual matrix can differ, but leaving a cell blank is a warning. “The API handles it” is not an accountable party.
Plan for exceptional states
Define authority during exchange decoupling, suspended trading, unavailable TSO signal, stale SOC, site isolation, negative available power, emergency stop and cyber incident. The optimizer may pause, the trader may close positions, and the site may revert to local/manual mode. Test those transitions before market pressure makes them necessary.
Frequently asked questions
What does a BESS optimizer do?
It calculates economically and operationally desirable bids, schedules, reserve allocations or dispatch targets from forecasts, positions and asset constraints.
Is a BESS optimizer an energy trader?
Not necessarily. A trader has market-access and order-management responsibilities. Some providers combine both functions; contracts should distinguish them.
What does a battery aggregator do?
It combines resources or customers into a portfolio for market or system participation and may optimize and dispatch them under contract. National rules define formal permissions.
What is a BRP?
Under EU balancing rules, a balance responsible party is a market participant or chosen representative responsible for its imbalances. Romania commonly uses PRE terminology.
Can VoltMage work with an existing trader or EMS?
Yes in principle. VoltMage components can integrate around existing market-access and site-control systems, subject to APIs, authority, security and project scope.
Sources and methodology
Sources were reviewed on 7 September 2026. Rules, participation requirements and product specifications can change; verify the current documents for the relevant asset and market before making a commercial decision.
- EU Regulation 2017/2195 — Electricity Balancing Guideline — Official BRP, BSP, imbalance and balancing definitions.
- ACER — electricity-market timeframes — Institutional relationship between markets and TSO balancing.
- IPTO — Registration Procedures — Country example of BSP, BRP, aggregator and storage-entity roles.
- OPCOM — DAM registration and procedures — Country example of exchange participation arrangements.
Make every market and control responsibility explicit.
Map forecasts, orders, BRP exposure, optimization, dispatch authority, telemetry and settlement across your counterparties and systems.
This article is technical and commercial information, not legal, regulatory, investment or trading advice.