Skip to main content
This guide is deprecated and no longer maintained. For current guidance on participating in FCR and aFRR ancillary service markets, see Ancillary services (virtual asset level).
This page covers how to manage virtual assets in FCR and aFRR ancillary services, covering market participation, bid submissions, capacity allocation between wholesale and ancillary services, SoC buffer requirements, revenue calculations and handling unavailabilities.

​
1. Where to find your available ancillary service capacities

Generally, your virtual asset comes with:
  • a marketable capacity available for aFRR positive and negative markets
    • the contractually available and therefore billable aFRR capacity
    • this capacity is available via API
    • it is only reduced in cases of unavailabilities
    • if you bid into ie. FCR, this capacity stays the same
  • a marketable capacity available for FCR markets → This is by law limited to 80% of the rated power for wholesale
    • the contractually available and therefore billable aFRR capacity
    • this capacity is available via API
    • it is only reduced in cases of unavailabilities
    • if you bid into ie. aFRR, this capacity stays the same
Remark: Beyond your marketable capacity, there is also your remaining available capacity for FCR and aFRR (this is your actually usable ie. aFRR capacity - which would also include reductions due to FCR committments). This information is currently not available via API and you have to make sure you take into account your remaining capacity yourself.
  • You can retrieve information on the marketable ancillary capacities through the operational endpoint
  • The three variables linked below are corresponding to each of the three formerly mentioned marketable capacities Image 11

​
2. Ancillary and wholesale blocks

The next chapter will briefly explain a fundamental concept of virtual batteries - the wholesale block. Understanding the wholesale block is a necessary foundation for understanding how ancillary services work on the LAYR, as there are many dependencies between the wholesale block and ancillary services. Wholesale block and ancillary services: Your available total power capacity is divided between ancillary service bids/commitments and remaining wholesale capacity which backs your wholesale trading activity. If you have bid capacity on the ancillary markets, that standing ancillary commitment is called aFRR or FCR block. The remaining wholesale capacity after deducting ancillary service bids/commitments is called wholesale block. The following figure gives a high level overview of how one power block is distributed between ancillary services and the wholesale block.
  • Your total available capacity is equivalent to your wholesale capacity, before you bid into ancillary markets
  • Of that total capacity, a certain part is prequalified for FCR and aFRR markets
  • Bidding into FCR or aFRR reduces the remaining wholesale block you have available until you receive market results.
  • Accepted FCR or aFRR bids ultimately reduce your the remaining wholesale block.
  • The graphic below visualises the wholesale block as the difference between total available capacity and your FCR and aFRR blocks on a high level Image 12

​
2.1 Get timeseries data of your wholesale block

  • You can identify the id of your wholesale block via Image 13
    • In this call you can expect an output as defined below, which includes the wholesale block id Image 14
  • Next you can query constant timeseries format information about your wholesale block Image 15
  • This timeseries contains the available power you have left for wholesale trading after deducting your ancillary commitments and your scheduled power in wholesale for each quarter
  • Exemplary output for a defined timespan of two quarters Image 16
  • Important note: calling the available capacity (marked in green) from the virtual asset endpoint without specifically referencing a block gives you the sum of ancillary and wholesale power available
  • However, the marketable ancillary capacities on this endpoint are already referencing to the specific market Image 17

​
2.2 Interdependencies of FCR and aFRR capacity

Your bidden or accepted FCR capacity always directly impacts your remaining aFRR and wholesale capacity. As the interdependencies can be complex, the following part will walk through a couple of examples to clearly outline how the three type of capacities interact.
  1. Scenario - Maximum FCR bid, no remaining aFRR
    1. Available capacities**:**
      1. Available wholesale capacity: 10MW
      2. Marketable aFRR: 8MW
      3. Marketable FCR: 8MW
      4. Energy capacity: 20MWh
      5. SoC bounds:
        1. 0%
        2. 100%
    2. Action: you bid 8MW into FCR
    3. Remaining capacities (as mentioned above, your marketable Ancillary capacities which are available via API stay the same)
      1. Remaining available wholesale capacity: 2MW
      2. Remaining available aFRR capacity:0MW
      3. Remaining available FCR capacity:0MW
      4. Energy capacity: 20MWh
      5. SoC bounds:
        1. 19.49%
        2. 82.78%
  2. Scenario - Maximum FCR bid, remaining aFRR
    1. Available capacities**:**
      1. Available wholesale capacity: 10MW
      2. Marketable aFRR: 10MW
      3. Marketable FCR: 8MW
      4. Energy capacity: 20MWh
      5. SoC bounds:
        1. 0%
        2. 100%
    2. Action: you bid 8MW into FCR
    3. Remaining capacities: (as mentioned above, your marketable Ancillary capacities which are available via API stay unchanged)
      1. Remaining available wholesale capacity: 2MW
      2. Remaining available aFRR capacity: 2MW
      3. Remaining available FCR capacity: 0MW
      4. Energy capacity: 20MWh
      5. SoC bounds:
        1. 19.49%
        2. 82.78%
  3. Scenario - aFRR bid
    1. Available capacities**:**
      1. Available wholesale capacity: 10MW
      2. Marketable aFRR: 10MW
      3. Marketable FCR: 8MW
      4. Energy capacity: 20MWh
      5. SoC bounds:
        1. 0%
        2. 100%
    2. Action: you bid 8MW into aFRR
    3. Remaining capacities: (as mentioned above, your marketable Ancillary capacities which are available via API stay unchanged)
      1. Remaining available wholesale capacity: 2MW
      2. Remaining available aFRR capacity: 2MW
      3. Remaining available FCR capacity: 1MW → not 2MW, because you would still need 25% of your FCR capacity free in the wholesale block and you can only bid in full MW steps
      4. Energy capacity: 20MWh
      5. SoC bounds: (no effect on SoC bounds)
        1. 0%
        2. 100%
  4. Scenario - Bidding more total ancillary capacity (8MW) than each of the two marketable capacities individually (6MW aFRR and 5MW FCR) [disclaimer: the following behaviour might not perfectly apply during a ramp up period where multiple assets are aggregated, of which not all are prequalified yet]
    1. Available capacities**:**
      1. Available wholesale capacity 10MW
      2. Marketable aFRR: 6MW
      3. Marketable FCR: 5MW
      4. Energy capacity: 20MWh
      5. SoC bounds:
        1. 0%
        2. 100%
    2. Action: you bid 5MW into aFRR and 3MW into FCR
    3. Remaining capacities: (as mentioned above, your marketable Ancillary capacities which are available via API stay unchanged)
      1. Remaining wholesale capacity 2MW
      2. Remaining available aFRR capacity: 1MW
      3. Remaining available FCR capacity: 1MW → not 2MW, because you would still need 25% of your FCR capacity free in the wholesale block and you can only bid in full MW steps
      4. Energy capacity: 20MWh
      5. SoC bounds:
        1. 7.31%
        2. 93.54% Important additional context for scenario 4:
      • FCR and aFRR capacities are not mutually exclusive
      • That means the sum of bids in FCR and aFRR can exceed the maximum of each marketable capacity individually (as you can see in scenario 4)
      • In operation, it does rarely happen that you can make use of this “stackable” structure because
        • You typically have around 80% of the assets capacity prequalified
        • That means the wholesale power buffers you have to keep for FCR bids are restricting this stackable behaviour (where the sum of both is bigger than the bigger of each individual as long as you have enough wholesale capacity available)

​
3. Buffer requirements of Ancillary Service Markets on LAYR

​
3.1 Deep-dive: FCR committed buffer power in wholesale block:

  • if you bid into FCR, your wholesale block always contains a certain share of power which constituted the dedicated buffer for your bid and accepted FCR power
  • the buffer capacity itself is not directly available as a number via API, but you can easily calculate the buffer.
  • this buffer capacity can be used for normal wholesale trading, but it cannot be bid into ancillary services
  • the main point of it is to have flexible power available to work against a very strong FCR activation (if necessary)
  • you will feel the impact of the reserved wholesale power in two ways
    • as restriction to how much you can bid into aFRR if you have active FCR bids
      • more under
    • how your FCR, aFRR and wholesale blocks are affected by an unavailability

​
4. FCR via LAYR

The next section covers how to use FCR via LAYR. Starting with bid sumission 4.1 Submitting FCR bids (including a deep dive on how FCR and aFRR bids affect each other 2.2 Interdependencies of FCR and aFRR capacity ) and how to call and update bids. Next we cover how to get results of your FCR bids Finally we cover how you can access FCR blocks, which are the result of FCR bids on a virtual battery

​
4.1 Submitting FCR bids

4.1.1 What to consider in FCR bids
  • All bids must be placed before 7:30 am CET/CEST on the day before delivery (The auction opens a week before the delivery day). If submitted before, bids are rejected
  • Offered Capacity (offeredCapacity) in a bid
    • must be provided in kilowatts (kW)
    • must be an integer multiple of 1 megawatt (MW). Any non-integral part will be rounded down (e.g., 1000.5 kW becomes 1000 kW), but values like 1500 kW would be rejected as they are not a multiple of 1 MW
    • must adhere to your available capacity for FCR bids
      • It must respect your marketable FCR capacity and the buffer requirements on the wholesale block
      • It must respect boundaries which might be imposed due to unavailabilities
  • Capacity Price (capacityPrice) in a bid
    • Must be provided in EUR/MW
    • The maximum bid price is 15,000 Euros, and the minimum is -15,000 Euros.
    • In the auction, the settlementPrice is determined by the “Pay As Clear” principle. This means the settlementPrice can be equal to or higher than the capacityPrice you submitted.
      • For instance, an accepted bid of 2000 kW with a capacityPrice of 80 EUR/MW could result in a settlementPrice of 100 EUR/MW, leading to a revenue of 200 EUR (100 EUR/MW * 2 MW).
4.1.2 API endpoint This is how you submit FCR bids via API.
4.1.3 Formatting in API usage: These are some notes on the formatting you need to adhere to while submitting FCR bids.
  • Delivery Day Format: The deliveryDay must be in YYYY-MM-DD format, for example, 2025-01-01.
  • Product Format: The product must follow the format NEGPOS_{{startEfaBlock}}_{{endEfaBlock}}, such as NEGPOS_00_04.
4.1.4 Exemplary bid submission (on EFA block level):
  • Units used in the response: kilowatts (offeredCapacity), EUR/MW (capacityPrice)
  • EUR/MW means one price for the whole 4h EFA block
    • EFA block = one of the 6x 4h blocks per day
    • This is the “granularity” of bids and prices on FCR markets (and also aFRR capacity markets) Image 18
4.1.5 Impact of FCR bids on the virtual asset
  • Once a valid bid is submitted, a new FCR block is added to the virtual asset, covering its duration.
    • The powerCapacity within this FCR block’s timeseries is set to the bid’s offeredCapacity for the delivery period.
    • Concurrently, the powerCapacity of the wholesale block (“market”:“WHOLESALE”) for the same delivery period is reduced by the offeredCapacity.
  • In other words: the power capacity which you bid into FCR is “reserved” for each EFA block or 15 minute period, until you get feedback of the auction results
    • The reduction of the wholesale block also leads to a respective reduction in available aFRR capacity
    • You can always calculate the available remaining capacity for aFRR and FCR by deducting your submitted bids for ancillary services from the originally available capacities or by querying the wholesale block
  • Furthermore, your SoC bounds get “tighter” according to the formula in 3. Buffer requirements of Ancillary Service Markets on LAYR
4.1.6 How to call SoC bound changes via API Image 19
  • stateOfChargeBoundsUpper: The upper bound of the state of charge of the virtual asset as a ratio, e.g. 0.9.
    • the bounds also reflect FCR based bound restrictions
  • stateOfChargeBoundsLower: The lower bound of the state of charge of the virtual asset as a ratio, e.g. 0.1.
    • the bounds also reflect FCR based bound restrictions

​
4.2 Get and update FCR bids

You mostly use this functionality to check the status quo of FCR bids and potentially adjust as a consequence. You will not see if bids are accepted here, you would have to query results as described in 4.3 Get FCR results. 4.2.1 Updating FCR Bids
  • FCR bids for a single product and delivery day can be called via a GET endpoint and updated using a PUT endpoint
  • You can submit the update in the same format as you submitted your initial bids, either on a full day basis or by specifically addressing certain EFA blocks/products
  • To delete a bid, you can set the request’s bid list to an empty list []
4.2.2 API endpoint This is how you get and re-submit FCR bids via the API.
  • getting current bids:
  • updating individual FCR bids
4.2.3 Exemplary output Image 20

​
4.3 Get FCR results

4.3.1 What to consider in FCR results
  • Results can be expected after 08:20am CET/CEST on the day before delivery (so roughly 80 minutes after submission deadline)
    • The exact publication time of results is not guaranteed
    • If results have not yet been published, returns an empty list and status code 200
4.3.2 API endpoint: This is how you get FCR results via the API.
4.3.3 Formatting in API usage: These are some notes on the formatting you need to adhere to while submitting FCR bids.
  • The query parameter deliveryDay must be in the following format: YYYY-MM-DD, e.g. 2025-01-01 (full day according to RFC3339)
  • The optional query parameter accepted can be used to filter the response to show only accepted or rejected bids. If the parameter is not set, all bids are returned
4.3.4 Exemplary FCR results:
  • a JSON representation of the FCR results for the given delivery day and virtual asset
  • This includes the product, deliveryDay, as well as a list of bids results for the given product
  • Each result in the results list contains the following fields:
    • accepted: A boolean field that shows whether the bid was accepted or rejected in the auction
    • offeredCapacity: The offered capacity of the original bid in kilowatts.
    • acceptedCapacity: The accepted capacity determined in the auction in kilowatts. Can be equal to or less than the offeredCapacity
    • capacityPrice: The capacity price of the original bid in EUR/MW
    • settlementPrice: The settlement price determined by the auction in EUR/MW. The price is determined by the “Pay As Clear” principle. It can be equal to or higher than the bid price for an accepted bid Image 21
4.3.5 Impact of accepted and not accepted FCR bids on the virtual asset
  • There are two options for your “reserved/bidden” capacity
    1. Your bidden capacity gets accepted and stays part of the FCR block (”nothing happens” refers to this case)
    2. Your bidden capacity gets rejected and moves back into the wholesale block
  • The power allocated to your virtual asset’s FCR block is increased and the available wholesale block power is reduced according to the results returned.
  • Both the FCR and wholesale blocks are adjusted based on the auction results. For example, if a bid is rejected, the powerCapacity is removed from the FCR block and added back to the wholesale block.
  • More specifically, per EFA block the following logic can be applied
    • If acceptedCapacity = offeredCapacity
      • nothing happens.
    • If acceptedCapacity < offeredCapacity (for the edge case that your offered capacity has just been at the cut-off point of the clearing price and not your whole capacity makes it into clearing)
      • the powerCapacity of the FCR block for the duration of the delivery period is reduced to the value of acceptedCapacity
      • whereas the powerCapacity of the wholesale block is increased by the same amount during that time.
      • same holds for the aFRR capacity available
    • If the bid is rejected altogether
      • the powerCapacity of the FCR block for the duration of the delivery period is reduced to 0 and the powerCapacity of the wholesale block is increased by the same amount.
      • aFRR capacity in the same way
  • SoC bound requirements as defined in 3. Buffer requirements of Ancillary Service Markets on LAYR → SoC bounds are callable as defined in 4.1.6 How to call SoC bound changes via API

​
4.4 Get FCR block

  • your accepted capacities in the FCR markets are called the FCR block
  • You can identify the ids of your virtual asset blocks via Image 13
    • In this call you can expect an output as defined below, which includes the FCR block id Image 14
    • To get constant timeseries format information about your FCR block, you can query Image 15
    • For FCR the block operational data contains the power you have allocated to FCR trading per quarter
      • This also allows you to understand, if an unavailability had an impact on your accepted FCR capacity
      • It does not yet contain how much remaining power you would have left from your FCR block

​
5. aFRR via LAYR

The next section covers how to use aFRR via LAYR. Starting with bid sumission (including a deep dive on how FCR and aFRR bids affect each other ) and how to call and update bids . Next we cover how to get results of your aFRR bids . Finally we cover how you can access aFRR blocks, which are the result of aFRR bids on a virtual battery.

​
5.1 Submitting aFRR bids

5.1.1 What to consider in aFRR bids
  • Submission deadlines
    • aFRR capacity markets
      • All bids must be placed before the following deadline: 8:40am CET/CEST on the day before delivery. The auction opens a week before the delivery day.
    • aFRR energy markets
      • All bids must be placed before the following deadline: 30 minutes before the delivery period, e.g. a bid for delivery period 15:30pm must be submitted by 15:00pm. Moreover, bids must be placed after 12:00pm CET/CEST on the day before delivery. If bids are made before that time, they are rejected.
  • Offered Capacity (offeredCapacity) in a bid
    • Must be provided in kilowatts
    • must be an integer multiple of 1 megawatt (MW). Any non-integral part will be rounded down (e.g., 1000.5 kW becomes 1000 kW), but values like 1500 kW would be rejected as they are not a multiple of 1 MW
    • must adhere to your available capacity for aFRR bids
      • It must respect your marketable/ still remaining aFRR capacity
      • It must respect boundaries which might be imposed due to unavailabilities
    • aFRR capacity markets - offeredCapacity
      • you are free to bid whatever capacity you intend
    • aFRR energy markets - offeredCapacity
      • you must bid at least the accepted capacity from the aFRR capacity market results
  • Price:
    • aFRR capacity markets - capacityPrice
      • Must be provided in EUR/MW/h. In the capacity market auction, a settlementPrice is determined by the “Pay As Bid” principle. It will match the capacityPrice of your bid.
      • For example, an accepted bid with capacityPrice = 100EUR/MW/h and acceptedCapacity = 2000kW will result in a revenue of 100EUR/MW/h * 2MW * 4h = 800EUR.
    • aFRR energy markets - energyPrice
      • Must be provided in EUR/MWh. In the energy market auction, a settlementPrice is determined by the “Pay As Clear” principle. It can be equal to or higher than the energyPrice you submitted.
      • For example, an accepted bid with energyPrice = 80EUR/MWh, settlementPrice = 100EUR/MWh and acceptedCapacity = 2000kW will result in a revenue of 100EUR/MWh * 2MW * 0.25h = 50EUR, if the asset is fully activated for the whole 15 minutes. It is important to note that you are only paid for the actual energy delivered.
      • If you have an accepted capacity market EFA block, you are not bound to the price of that EFA block → that means you can bid a higher or lower price in the energy markets on quarter hours during the EFA block than you have bid originally in the capacity markets for the respective EFA block
    • The max price that can be bid into both markets is 15,000 Euros, the min price is -15,000 Euros.
5.1.2 API endpoint This is how you submit aFRR bids via API.
5.1.3 Formatting in API usage: These are some notes on the formatting you need to adhere while submitting aFRR bids.
  • aFRR capacity markets
    • For a bid in the capacity market (Regelleistungsmarkt), it is required to provide both the capacityPrice and energyPrice. The product must be in the following format: {{direction}}_{{startEfaBlock}}_{{endEfaBlock}}, e.g. POS_00_04.
  • aFRR energy markets
    • For a bid in the energy market (Regelarbeitsmarkt), it is required to provide the energyPrice. The capacityPrice field can be removed or set to null ("capacityPrice": null), depending on your preference. The product must be in the following format: {{direction}}_{{quarterHourInDay}}, e.g. POS_001. The final products on a normal day are POS_096 or NEG_096. The final products on the CET to CEST clock change day are POS_092 or NEG_092. The final products on the CEST to CET clock change day are POS_100 or NEG_100
  • The productDateCode in the response references a specific product on a given delivery day: e.g. 2025-01-01_POS_00_04. This “product-date-code” can be used to update the bid individually through the PUT endpoint.
5.1.4 Exemplary capacity market bid submission (on EFA block level):
  • Units used in the response: kilowatts (offeredCapacity), EUR/MW/h (capacityPrice) and EUR/MWh (energyPrice).
  • EUR/MW/h means one price for one hour in the 4h EFA block
    • EFA block = one of the 6x 4h blocks per day
    • This is the “granularity” of bids and prices on FCR markets (and also aFRR capacity markets)
Image 23 5.1.5 Impact of aFRR bids on the virtual asset
  • Once a valid bid has been submitted, a new aFRR block ("market":"AFRR") is added to the virtual asset.
    • The block will cover the duration of the whole virtual asset. Inside the block’s power capacity timeseries, the powerCapacity is updated to value of the bid’s offeredCapacity for the delivery period of the product you bid on.
    • At the same time, the powerCapacity of the wholesale block ("market":"WHOLESALE") for the delivery period of the product you bid on is reduced by the offeredCapacity.
    • Both the aFRR and the wholesale block will be adjusted according to the auction results. E.g. if a bid is rejected, the powerCapacity is removed from the aFRR block and added to the wholesale block.
  • In other words: the power capacity which you bid into aFRR is “reserved” for each EFA or quarter hour block, until for aFRR capacity you get feedback on your bid of the auction results / for aFRR energy your bid will be reserved either way
    • This “reserved” power capacity is deducted from your available FCR and wholesale power capacity
    • In contrast to FCR, there are no specific SoC buffer requirements enforced for aFRR

​
5.2 Get and update aFRR bids

You mostly use this functionality to check the status quo of aFRR bids and potentially adjust as a consequence. You will not see if bids are accepted here, you would have to query results. 5.2.1 Updating aFRR Bids
  • aFRR bids for a single product and delivery day can be called via GET endpoint updated using a PUT endpoint
  • You can submit the update in the same format as you submitted your initial bids, either on a full day basis or by specifically addressing certain EFA blocks/quarters/products
  • To delete a bid, you can set the request’s bid list to an empty list []
5.2.2 API endpoint: This is how you get and re-submit aFRR bids via API.
  • getting current bids:
    • The optional query parameter market can be set to capacity or energy. capacity will only return aFRR bids made to the capacity market (Regelleistungsmarkt). energy will only return aFRR bids made to the energy market (Regelarbeitsmarkt). If the flag is not set, both will be returned.
  • updating individual aFRR bids
5.2.3 Exemplary output Image 23

​
5.3 Get aFRR results

5.3.1 What to consider in aFRR results
  • aFRR capacity markets
    • after 09:20am CET/CEST on the day before delivery (so roughly 40 minutes after submission deadline)
      • The exact publication time of results is not guaranteed.
      • If results have not yet been published, returns an empty list and status code 200.
  • aFRR energy markets
    • results can be expected around or after 23 minutes before the delivery period, e.g. for a bid with delivery period 12:30pm, results are expected around 12:07pm.
      • The exact publication time of results is not guaranteed.
      • If results have not yet been published, returns an empty list and status code 200. What aFRR energy market results contain
      • aFRR energy market results include the amount of capacity you have been awarded based on your bids
      • your actual activation and the respective payout is subject to the TSOs AGC signal
      • the acceepted capacity in aFRR energy markets is still highly relevant, as you are not allowed to participate with this capacity in intraday trading!
      • that means this capacity will not be part of your wholesale block
      • all capacity which is not accepted, it moves back into your wholesale block
5.3.2 API endpoint: This is how you get aFRR results via API.
5.3.3 Formatting in API usage: These are some notes on the formatting you need to adhere while submitting aFRR bids.
  • The path parameter productDateCode specifies a unique product and delivery day pair: YYYY-MM-DD_{{productName}}, e.g. 2025-01-01_POS_00_04 for a capacity market product (Regelleistungsmarkt) or 2025-01-01_POS_001 for an energy market product (Regelarbeitsmarkt).
  • The delivery day inside the productDateCode path parameter must be in the following format: YYYY-MM-DD, e.g. 2025-01-01 (full day according to RFC3339).
  • The optional query parameter accepted can be used to filter the response to show only accepted or rejected bids. If the parameter is not set, all bids are returned.
5.3.4 Exemplary aFRR results:
  • a JSON representation of the aFRR results for the given delivery day and virtual asset. This includes the product, deliveryDay, as well as a list of bids results for the given product
  • Each result in the results list contains the following fields:
    • accepted: A boolean field that shows whether the bid was accepted or rejected in the auction
    • offeredCapacity: The offered capacity of the original bid in kilowatts.
    • acceptedCapacity: The accepted capacity determined in the auction in kilowatts. Can be equal to or less than the offeredCapacity
    • capacityPrice: The capacity price of the original bid in EUR/MW/h
    • energyPrice: The energy price of the original bid in EUR/MWh
    • settlementPrice: The settlement price determined by the auction in EUR/MW/h (capacity market bid) or EUR/MWh (energy market bid).
      • In the capacity market auction, the settlementPrice is determined by the “Pay As Bid” principle. It will match the capacityPrice for an accepted bid.
      • In the energy market auction, the settlementPrice is determined by the “Pay As Clear” principle. It can be equal to or higher than the energyPrice for an accepted bid
Image 24 5.3.5 Impact of accepted and not accepted aFRR bids on the virtual asset
  • There are two options for your “reserved/bidden” capacity
    1. Your bidden capacity gets accepted and stays part of the aFRR block (”nothing happens” refers to this case)
    2. Your bidden capacity gets rejected and moves back into the wholesale block
  • The power allocated to your virtual asset’s FCR block is increased and the available wholesale block power is reduced according to the results returned.
  • If acceptedCapacity = offeredCapacity
    • nothing happens.
  • If acceptedCapacity < offeredCapacity
    • the powerCapacity of the aFRR block for the duration of the delivery period is reduced to the value of acceptedCapacity
    • whereas the powerCapacity of the wholesale block is increased by the same amount during that time.
    • FCR bidding window has already closed, hence no impact on your available FCR capacity
  • If the bid is rejected altogether
    • the powerCapacity of the aFRR block for the duration of the delivery period is reduced to 0 and the powerCapacity of the wholesale block is increased by the same amount.
    • FCR bidding window has already closed, hence no impact on your available FCR capacity

​
5.4 Get aFRR block

  • your accepted capacities in the aFRR markets are called the aFRR block
  • You can identify the ids of your virtual asset blocks via Image 13
    • In this call you can expect an output as defined below, which includes the aFRR block id Image 14
  • To get constant timeseries format information about your aFRR block, you can query Image 15
  • For aFRR the block operational data only contains the power you have allocated to aFRR trading per quarter
    • This also allows you to understand, if an unavailability had an impact on your accepted aFRR capacity
    • It does not yet contain how much remaining power you would have left from your aFRR block

​
6. Revenue calculation

The following part briefly walks through how you can interpret the price units on the LAYR and how you can use these to calculate revenue per market. Definitions are in line with market standards, but still worth a brief definition.

​
6.1 FCR revenue

  • capacity price unit: EUR/MW
  • auction type: Pay as clear
  • product delivery duration: 4h (whole duration is paid as one)
  • revenue calculation example:
    • settlement (clearing) price: 100 Euro/MW
    • accepted capacity: 2 MW
    • revenue: 100 Euro/MW * 2 MW = 200 Euro
    • delivery: 2MW over 4 hours for 200 Euro

​
6.2 aFRR Capacity

  • capacity price unit: EUR/MW per hour of delivery
  • auction type: Pay as bid
  • product delivery duration: 4h (every hour is paid)
  • revenue calculation example:
    • capacity price: 100 Euro/MW/h
    • accepted capacity: 2MW
    • revenue: (100 Euro/MW/h * 2 MW) * 4 h = 800 Euro Revenue=(100Euro/MW/h×2MW)×4hRevenue = (100Euro/MW/h \times 2MW) \times 4h
    • delivery: 2MW over 4 hours for 800 Euro

​
6.3 aFRR Energy

  • energy price unit: EUR/MWh, based on activation
  • auction type: Pay as clear
  • product delivery duration:
    • 15min
    • power is not consistent and depends on activation
    • at given granularity (e.g. 4 seconds), we take power measurements within 15 minute period, divide by granularity per hour to get TotalEnergy value
  • revenue calculation by terralayr (4 second granularity)
TotalEnergy=∑4secondsP(4seconds)60mins∗60seconds/4secondsTotal Energy=\sum_{4seconds}\frac{P(4seconds)}{60mins*60seconds/4seconds} TotalRevenue=TotalEnergy(MWh)×EnergyPrice(EUR/MWh)TotalRevenue = TotalEnergy(MWh) \times EnergyPrice(EUR/MWh)
  • example:
    • settlement (clearing) price: 100 Euro/MWh
    • activated capacity: 2MW (sum of activated energy in 1/4 second for 15 minutes)
    • example revenue for full activation for 15 minutes: 100 Euro/MWh * 2MW * 0.25h = 50 Euro

​
7. Ancillary services and re-validation

We will briefly walk through a scenario in which ancillary activation brings your SoC projection out of bounds to clearly pin down consequences and playing room you have. 7.1 Scenario
  • You have an accepted wholesale schedule which keeps your SoC within the SoC bounds
  • Ancillary activation (which is a result of your accepted ancillary bids) suddenly pushes your projected SoC out of bounds
→ we will cover different scenarios in the following part, depending on when SoC gets pushed out of the bounds and what your scheduled power is for the next quarter 7.2 What happens at several steps along the validation timeline Note: All power schedules below correspond to wholesale power. Case 1: SoC projection for the next quarter gets out of bounds before re-validation (before 7 minutes prior to delivery):
  1. Option: Your scheduled power is in the “right” direction and enough to move projected SoC back into the SoC bounds
    1. free Action in re-validation: no action is taken
    2. Remaining playing room: You can still submit other power values subject to conditions before re-validation (specifically, as long as they are keeping the SoC projection within the bounds)
  2. Option: Your scheduled power is in the “right” direction (at the maximum available power) level, but it is not enough to move SoC projection back into the SoC bounds
    1. free Action in re-validation: no action is taken
    2. Remaining playing room: You can not submit other power values, because any reduction of power would move your projected SoC even further away from the bounds.
  3. Option: Your scheduled power is in the “right” direction (not on the maximum available power), but it is not enough to move SoC projection back into the SoC bounds
    1. Action in re-validation: your power is corrected in a way that brings the SoC projection back into the bounds (or as close as possible) within the next quarter
    2. Remaining playing room: After re-validation you can still submit other power values subject to conditions before re-validation (specifically, as long as they are keeping the SoC projection within the bounds)
  4. Option: Your scheduled power is zero, so it does not help moving the SoC projection back in direction of the SoC bounds
    1. Action in re-validation: your power is corrected in a way that brings the SoC projection back into the bounds (or as close as possible) within the next quarter (this means increasing the power from a status quo of 0)
    2. Remaining playing room: After re-validation you can still submit other power values subject to conditions before re-validation(specifically, as long as they are keeping the SoC projection within the bounds)
  5. Option: Your scheduled power is in the “wrong” direction, so it is moving the SoC projection away from the SoC bounds
    1. Action in re-validation: your power is corrected in a way that brings the SoC projection back into the bounds (or as close as possible) within the next quarter (this means changing the direction of power)
    2. Remaining playing room: After re-validation you can still submit other power values subject to conditions before re-validation (specifically, as long as they are keeping the SoC projection within the bounds)
Case 2: SoC projection gets out of bounds after re-validation but before gate-closure (later than 7 but before 5.30 minutes prior to delivery): Note:
  1. Option: Your scheduled power is in the “right” direction = moving SoC projection back in direction of the bound
    • Action in time after re-validation but before gate-closure: no action is taken
    • Remaining playing room: You can correct your power value, as long as new schedule brings your SoC projection back into the bounds (that is the only accepted changed schedule at this point)
  2. Option: Your scheduled power is zero = no effect on moving SoC projection back in direction of the bound
    • Action in time after re-validation but before gate-closure: no action is taken
    • Remaining playing room: You can correct your power value, as long as new schedule brings your SoC projection back into the bounds (that is the only accepted changed schedule at this point)
  3. Option Your scheduled power is in the “wrong” direction = moving SoC projection in direction away of the bound
    • Action in time after re-validation but before gate-closure: no action is taken
    • Remaining playing room: You can correct your power value, as long as new schedule brings your SoC projection back into the bounds (that is the only accepted changed schedule at this point)
Case 3: SoC gets out of bounds after gate-closure (later than 5.30 minutes prior to delivery):
  1. Option: Your scheduled power is in the “right” direction = moving SoC projection back in direction of the bound
    • Action in time after re-validation but before gate-closure: no action is taken
    • Remaining playing room: none
  2. Option: Your scheduled power is zero = no effect on moving SoC projection back in direction of the bound
    • Action in time after re-validation but before gate-closure: no action is taken
    • Remaining playing room: none
  3. Option Your scheduled power is in the “wrong” direction = moving SoC projection in direction away of the bound
    • Action in time after re-validation but before gate-closure: no action is taken
    • Remaining playing room: none

​
8. Unavailabilities and ancillary services

The last chapter will cover the effects of unavailabilities on ancillary bids and accepted capacities. One remark on the SoC management obligations with and without unavailabilities:
  • without unavailability: it is fully the users responsibility to handle SoC management according to ancillary market regulation. As long as the virtual asset baseline conditions stay as they have been agreed on stay the same. i.e. no platform outage, not nonsense data everything and everything working as usual
  • with unavailability or deviations from the agreed on baseline conditions: the user should still handle SoC management with best efforts.

​
8.1 Effect of unavailability on bid capacity

  • Your wholesale block and available ancillary capacity is reduced / scaled down following the same mechanism.
  • If you have existing bids (before gate-closure of the respective markets) these are also reduced / scaled down following the same mechanism.
  • If you have existing bids after gate-closure but before results are published, you have to wait for the results and awarded capacity.

​
8.2 Ancillary service effects during planned & unplanned unavailability - on awarded capacity

The following chapter outlines how unavailabilities affect ancillary and wholesale power.

​
8.2.3 Power capacity types

There are four “types” of power, which behave differently in the context of unavailabilities. Those are:
  1. Free wholesale power block
  2. aFRR committed power
  3. FCR buffer in wholesale power block
    • this amounts to 25% of FCR committed power
  4. FCR committed power
Mechanism:
  • Power capacities are deducted according to above order
  • The wholesale block is always reduced first
  • After that aFRR, FCR wholesale buffer and FCR in respective order
  • Most importantly:
    • FCR:
      • FCR is prioritised over aFRR capacity and energy markets (when we talk about aFRR power, we relate to both markets)
      • FCR buffer wholesale power is kept at the same ratio to FCR as in the first place (recall this is 25% wholesale power of accepted FCR power)
      • That means your free power in the wholesale block always fulfils your legal power buffer obligations
      • edge case: the 1.25MW in between each full FCR step are allocated to the aFRR block (until it is possible to allocate a full FCR + wholesale block combined MW of 1.25 again). This approach is potentially subject to change in the future
    • aFRR:
      • We do not keep any wholesale buffers on your aFRR commitments
      • If you end up in a situation with 100% of your available power capacity committed into aFRR, because your wholesale block become fully unavailable, you should
        • Try to get SoC close to 50% as soon as possible
        • navigate with aFRR energy bids conservatively around the 50% SoC
        • bid the maximum price to reduce probability of getting activated, in situations where this becomes necessary
          • i.e. you are at lower SoC bound and you have an existing aFRR downard commitment from the capacity markets → you should bid at the maximum price into the energy downward markets inorder to prevent further discharge activation → you could try to bid into aFRR upward markets to recharge the asset
How to query changes to power capacity via API:
  • how to get available capacity
    • available FCR and aFRR capacity is equal to marketable capacity
    • there is no “rated” capacity endpoint for now (coming soon)
    • that means, marketable capacity for aFRR and FCR changes according to unavailabilities

​
8.2.4 Energy capacity types

Mechanism:
  • As outlined in the chapter Virtual Asset Unavailabilities if your Energy capacity is reduced
    • your relative SoC is kept the same
    • that means your SoE reduces and some of your SoE is “frozen” in the unavailable part of your virtual battery
  • That means you could end up in a situation where you had sufficient SoC buffers but the unavailability brings you into a regime where the SoC buffers are not sufficient anymore (FCR bids stay stable but energy capacity reduces)
  • In this case, you should try at best efforts to return into the area between SoC bounds again!
How to query changes to energy capacity via API:

​
8.2.4 SoC bound effects

  • SoC bounds might change if the “relation” of FCR bids to available energy capacity changes
    • Lower bound in %: 0.458 * FCR_power / sqrt(RTE) / Energy_capacity) Upper bound in %: 1 - (0.458 * FCR_power * sqrt(RTE) / Energy_capacity)
  • With reducing energy capacity but potentially stable FCR bids (if only wholesale block is reduced) the SoC bounds can get more strict after an unavailability

​
8.3 Scenarios and examples

The following two scenarios cover the main two “complex” cases of unavailabilities, which you could face in context of ancillary services.

​
8.3.1 Scenario 1: SoC bounds get squeezed

Scenario:
  • In the first scenario, the unavailability reduces your energy capacity stronger in relative terms, than your bid FCR power.
    • Such a change is consequence of the “prioritisation” of FCR power in the curtailing process
  • That leads to stricter SoC bounds (check 8.2.4 SoC bound effects and assume FCR_power reduces less than Energy_capacity)
  • The SoC of your virtual asset was so low, that after the unavailability comes into place, your SoC is out of bounds
Recommended behaviour: Bring your SoC back into the bounds as soon as possible with the remaining wholesale capacity you have available, at best efforts Baseline: Image 26 Post unavailability: Image 27

​
8.3.2 Scenario 2: aFRR commitments without wholesale power left

Scenario:
  • In the second scenario, you have active aFRR commitments in the capacity markets and remaining wholesale power
  • The unavailability completely reduces your wholesale block and you have only aFRR committed power remaining
  • As you are not legally required to keep a power buffer for your aFRR commitments, the platform does not keep a wholesale power buffer as it did for FCR power
Recommended behaviour: If you end up in a situation with 100% of your available power capacity committed into aFRR, because your wholesale block become fully unavailable, you should:
  • take SoC management into account for your bidding strategy (opportunity costs of not being able to service aFRR activations because you are on SoC bounds might be very high)
    • i.e. you are at lower SoC bound and you have an existing aFRR downard commitment from the capacity markets → you should take that into account when coming up with a price for the energy downward markets → you could alternatively try to bid into aFRR upward energy markets to recharge the asset
Baseline: Image 28 Post unavailability: Image 29

​
8.4 Ancillary service effects during short-notice unavailability - on awarded capacity

​
8.4.1 Short notice behaviour

For the current plus four quarters after announcement of an unavailability, the following allowances hold: Power effects:
  • Bid and accepted FCR capacity remains
    • FCR bids and commitments can not protected by the short notice periods
    • There are no ancillary returns on unavailable capacity and there is no forwarded activation
    • Your “Besicherung” is jumping in
  • Bid and accepted aFRR capacity remains
    • aFRR bids and commitments can not be protected by the short notice periods
    • There are no ancillary returns on unavailable capacity and there is no forwarded activation
    • Your “Besicherung” is jumping in
  • The scheduled wholesale power can remain or be changed subject to the rules defined in Virtual Asset Unavailabilities - except in the special case defined below Special case: Ancillary activation and short-notice protected wholesale Scenario
    • Ancillary activation pushes your SoC projection out of bounds for the upcoming quarter
    • That quarter is short-notice protected
    • Your wholesale schedule for this quarter is not yet at level of the the maximum available power to bring the SoC projection back into the bounds Action
    • In such a case, applying to the legal SoC bounds is more important than the short-notice protection
    • Even short notice protected power values will be corrected in the re-validation. If your projected SoC is out of SoC bounds due to sudden ancillary activation

​
Scenario 3: SoC bounds get squeezed - short-notice

Scenario:
  • In the third scenario, the unavailability reduces your energy capacity stronger in relative terms, than your bid FCR power.
    • Such a change is consequence of the “prioritisation” of FCR power in the curtailing process
  • That leads to stricter SoC bounds
  • The SoC of your virtual asset was so low, that after the unavailability comes into place, your SoC is out of bounds
Recommended behaviour: While you can leave your “short-notice” protected schedule as it is, you should bring your SoC back into the bounds as soon as possible with the remaining wholesale capacity you have available. Baseline: Image 30 Post unavailability: Image 31
Last modified on July 23, 2026