CAPRI Online Manual (update)

For the European Union, the CAPRI programming models cover in rich detail the different coupled and de-coupled subsidies of the so-called first Pillar 1 of the CAP, as well as major ones from Pillar 2 (i.e., Less Favoured Area support, agri-environmental measures, Natura 2000 support). The interaction between premium entitlements and eligible hectares for the Single Farm Payment (SFP) of the CAP is explicitly considered, as are the different national SFP implementations, possibly remaining coupled payments (previously under article 68 of Council Regulation (EC) No. 73/2009, from 2014 as “Voluntary Coupled Support”).

Decoupled payments – as with other premium schemes of the CAP from the present and past – are simulated in CAPRI relatively closely to their definition in existing legislation. The rather high dis-aggregation of the model template regarding production activities and the resolution by farm types inside of NUTS 2 regions clearly eases that task. Currently, 260 different voluntary coupled support schemes are implemented, in addition to decoupled income support (Basic Payment Scheme, BPS).

The payments – both in reality and in the model – tend to be defined in a cumulative manner. In 1992, the direct payments were introduced based on the previous price support levels multiplied by regional historic reference yields. The payments therefore became regionally differentiated. In the subsequent decoupling under Agenda 2000 and the following reforms, the single farm payments were defined based on the payments that each farm had previously received. The payments got very different expressed per hectare for farms in high yield regions versus low yield regions and for farms that had held animal payments versus arable farms. Then, the 2013 reforms introduced convergence of payment rates, both across farms (internal convergence) and between member states (external convergence). CAPRI reflects these incremental reforms, so that the payment rates in the most recent reform are based on coupled payments from MacSharry times.

Given that each reform has added complexity to the previous system, so too has the premium module of CAPRI grown to maintain the capacity to model previous reforms while allowing novel features such as greening to be introduced. Nevertheless, two generic features can be distinguished, that form the basis for many payments: the basic concept of a premium payment, and the idea of payment entitlements. Those are treated in separate sections here. Then, we proceed to describe the incremental reforms of the first pillar of the CAP, starting with the most recent, and the implementation of selected second pillar payments. Finally, we discuss certain elements relating to the reporting of premium payments, most notably the financing over different budgets.

In the CAPRI supply module, premiums are always paid per activity level (per hectare or per animal) basis. They can be differentiated by the low and high yield variant of each crop activity. The premiums are calculated in the premium module from different premium schemes.

A premium scheme (such as DPGRCU for the Grandes Cultures premiums after the Fischler reform) is a logical entity which encompasses:

1. A specific application type (defining the basis for the payment amount)
2. a region or regional aggregate to which it is applied,
3. Possible ceilings in entitlements (CEILLEV) and in value (CEILVAL)
4. Payment rates for possibly several lists of activities (such as PGGRCU for all types of Grandes Cultures or PGPROT for protein crops).
5. Optionally an indication of the marginal payment when a ceiling is reached
6. Optionally a modifier for different amounts per technology

The schemes provide many-to-many mappings between policy instruments and agricultural activities: each scheme can apply to many different activities – with possibly differentiated rates – and each activity can draw support from different schemes.

The application type defines how the nominal amount (called PRMR) is applied. Currently, the following application types are supported:

• perLevl = per ha or head
• perSlgtHd = per slaughtered head
• perYield = per unit of main output
• perHistY = per historic yield
• perLiveStockUnit = per livestock unit
• noDirPay = Norwegian direct payment
• noPriceSup = Norwegian price support

The application type points to a factor by which the nominal amount PRMR (for PRemiuM in Regulation) is converted to a declared value per hectare or head (PRMD). For perLevl, the factor is unity (it is already per hectare), but for instance for perYield, the amount is interpreted as a payment per unit of main output. That is used for the Nordic Aid Scheme for dairy cows in the northmost parts of Europe and for coupled payments in Norway.

Each payment is defined for one or seveal groups of activities, functioning as lists of eligible activities. Additionally, the payment can be applied in different rates to the high and low yield variant, to model e.g. an extensification premium.

Each premium scheme also has up to two ceiling values:

• ceilLev = Ceiling on LEVL, i.e. the number of hectares or heads
• ceilVal = Ceiling on the total budget (envelope) spent on the scheme

In the basic setting, the ceilings work as the old Grandes Cultures payment: if the total quantity (hectares or amount) exceeds the ceiling, then the payment to each farmer is reduced so that the ceilings are respected. This means that the marginal payment is somewhat reduced but does not become zero. For some other schemes, such as the Basic Payment Scheme of the CAP 2014-2020, there is a hard limit on the number of payment entitlements, so that the marginal payment becomes zero if the ceiling is overshot. That behaviour can be triggered by including the payment scheme set element in a special set PSDPAY_cutEndog, as in the following example from “pol_input\mtr_until2013.gms”.

PSDPAY_cutEndog(“DPSAPS”) = YES;
PSDPAY_cutEndog(“DPREG”) = YES;
PSDPAY_cutEndog(“DPFRMS”) = YES;
PSDPAY_cutEndog(“DPFRMF”) = YES;
PSDPAY_cutEndog(“DPGREEN”) = YES;

The following figure shows the technical implementation at an example:

Figure 14: Example of technical implementation of a premium scheme

Source: CAPRI Modelling System. Note: The parameter PPDATA_E is now called p_premDataE.

The sets of payments, exemplified by DPGRCU in the figure, and the activity groups, exemplified by PGGRCU and PGPROT are defined in the file policy\policy_sets.gms. Since this is a “static” GAMS file used in any simulation, it contains the gross list of all policies that currently can be simulated, including legacy ones. In order to work efficiently with the acronyms which define the application types, these are converted to numerical attributes as shown below (‘policy\policy.gms’):

CAPRI also provides the possibility to incentivise extensification or intensification via the payments. Most production activities come in technological variants, by default one higher yielding and one lower yielding one, and those variants can be eligible to different rates of premium payments. This is used for instance in the implementation of agri-environmental schemes in the file policy\rd_logic.gms as shown in the figure below. The parameter p_technFact is the standard coefficient that modifies the technology of the production activities in CAPRI. In the figure below, the two statements change the rate of premium payments for the set of currently active regions (rs), for all model activities (MPACT), for all agri-environmental schemes (psdpay_ae) with different rates for technology T1 (high yield) and T2 (low yield) in the case where T2 exists. +0.5 for T2 means that the premium payment in the model becomes the nominal rate times (1 + 0.5), i.e. 50% higher, whereas the -0.5 for T1 means that the premium payment in the model becomes the nominal rate times (1 – 0.5), i.e. 50% lower. This approximates the stylized fact that agri-environmental schemes, which in reality consist of a wide range of measures, in general favour extensive technologies (see section on Pillar II payments below).

The general flow of logic inside of CAPRI (inside the model file capmod.gms) as regards premiums is shown in the following figure. The process starts by loading baseline data, including calibrated behavioural parameters. That data set represents an equilibrium situation for the policy (premiums) that were used in the baseline generation process.

After loading data, the file with declarations of all available premium schemes et cetera (policy_sets.gms) is loaded. The particular policy to use in the present simulation is contained in the policy file with the name defined by the placeholder (environment/macro variable) %result_type%. This string will also be part of the file name used for the simulation results.

The premiums defined in the policy file is processed by the file policy.gms. That processing implies a translation of the regulation-like definitions used in the policy file to parameters useful for CAPRI.

Within the simulation algorithm itself, a special file called prmcut.gms is called repeatedly, with the purpose to cut effective premium rates paid in case any ceiling is overshot, so that budgets are respected.

Figure 15: General flow of logic of CAPRI model as regards premiums

Source: own illustration

Generally, all attributes for a premium scheme are mapped down in space, e.g. from EU27 to EU 27 member states, from countries to NUTS1 regions inside the country, from there to the NUTS2 regions inside the NUTS1, and from NUTS2 regions to the farm types in a NUTS2 region (see ‘policy\policy.gms’), e.g.

In order to map the premium rate as defined in a legal text into one paid out on a per-activity basis, the relevant activity based attribute matching the application type is set to a premium modification factor (“Ap_premModfFactT”) as shown below:

The actually declared premium per activity unit (ha, [1000] [slaughtered] heads) is then the multiplication of the premium rate and that modification factor. For crops, the unit of the resulting entries are current € per ha, for animal, it depends on the exact definition of the activity level (per [1000] [slaughtered] heads).

These declared rates can hence be aggregated to higher regional units using the activity levels as weights, e.g. from farm types to NUTS2:

Before the supply module is started between iterations, the current activity levels and premiums paid out are summed up for each scheme and regional level where ceilings in levels or value are defined. If one of the aggregated sums exceeds the ceilings, all premium rates for the scheme are cut proportionally to fit under the tighter of the two envelops:

From the declared rates and these cut factors, the actually paid premiums are defined:

The indivudal premiums from each premium scheme are then added up to arrive at one average rate for each activity which enters the objective function of the supply model, the data base and post-model reporting:

We explain the different elements and steps in the following based on an example of the slaughter premium for adult cattle of 80 EURO per slaughtered head in Latvia, defined in 2004. The following screen shot comes from the policy file gams\pol_input\mtr_until2013.gms, with some lines hidden.

1. The application type defines the criterion upon which the payment depends, in the case of the slaughter premium it is defined per slaughtered head.
2. The regulation premium rate (PRMR) is the default (maximum, uncut) amount of the premium according to regulatory texts, for all activities coverd by the premium group (here PGMEAT) and regions for which the premium is defined. In the example, this means that it is 80 EURO for the group of activities PGMEAT, which is dairy cows, suckler cows, male adult cattle and fattened heifers, in Latvia (LV000000). This is defined in a hierarchical way: if it is set to 80 EURO for the EU and not set at all at lower regional level, the 80 EURO are mapped down to all sub regions by the program. The program also lets you define groups of activities that are linked to the premium. In this case a group PGMEAT has been defined which contains the relevant animals (set s_PSGRP(*) in the file ‘policy_sets.gms’).
3. The declared amount in the activity definition of CAPRI (per ha, per head, per 1000 heads) way that the amount PRMR should be applied or declared in CAPRI is called declared premium (PRMD) and applies per head or hectare. In our example, the regulation says that 80 EURO should be paid when the animal is slaughtered. That means that in order to get the amount per living animal and year, the 80 EUROs have to be multiplied by the frequency with which the animal is slaughtered. For male beef cattle it is 1/year whereas it for dairy cows is something like 1/5 years. These numbers come from the CAPRI database.
4. Regional ceiling, expressed in maximum number of premiums paid and/or total payment in EURO. In the example with the slaughter premiums, this is used to set a national ceiling limiting the total amount spent on slaughter premiums to 9.946 million euro. There can be additional ceilings at other regional levels, and the most strongly binding is always the one that limits payments.

Those four pieces of information are generally easily accessible without further processing from the regulatory texts. Starting with PRMR and APPTYPE (information pieces 1 and 2 above), it is possible to calculate (3), PRMD, the amount of premium per head or hectare that would be paid if there were no (active) ceiling. These preparatory calculations, e.g. the hierarchical break down from higher to lower regional level and from activity groups to individual activities, as well as the calculations of PRMD from PRMR (using APPTYPE) is carried out in a file called ‘policy\policy.gms’ as shown above.

For most premiums in CAP there are ceilings, which if they are binding decrease the average amount of premiums actually paid (effective premium, PRME) per head or hectare. As discussed, due to the different kind of ceilings, the reduction of premiums and the treatment of PRME can only be done endogenously during the simulations depending on the simuled production patterns.

How is this problem solved in CAPRI? The effective premium (PRME) is exogenous during the optimisation of the supply model¹⁾, but adjusted iteratively between the main model iterations. So, for most premium schemes, the premium level is constant in the objective function and hence the model does not realise that the marginal premium payment is zero as soon as the ceiling is reached. Technically, the iterative adjustment of the effective premiums PRME is handled in a file called ‘policy\premcut.gms’ for “premium cut”. That reasoning is correct as long as the ceiling is not farm specific.

In each iteration, once all regional model are solved, the program adds up total number of premium units (hectares or heads for which it is paid) that belong to each ceiling. In most cases this simply means summing up number of animals or hectares of the activities for which each premium applies. This is also multiplied with the declared amount PRMD to get the total payment which would be paid if it would not be cut. For each premium this is compared to the ceilings defined (total level with the level ceiling and total amount with the value ceiling) and a “cut factor” is calculated, which defines how much the premium has to be reduced in order to fit under all ceilings. Then PRMD is multiplied by this factor to get the effective premium (PRME) for the next iteration.