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’):