Payment mechanism

[duncandewhurst]

SIF's SOURCE platform includes a Contractual Arrangement field with the following codelist:

• User-pays PPP
• Government Pays PPP
• PPP
• Concession
• Lease to Concession Transformation (specific to Ukraine)
• Design Build Operate
• Design Build Maintain
• Design and Build
• Build Only

This codelist seems to mix information on the functions that the private sector is responsible for (Design, Build, Operate, Maintain), the payment mechanism (user or government) and the contract arrangement (PPP, concession, lease to concession).

Information on the functions can be mapped to the expanded contract nature codelist discussed in #245, however OC4IDS doesn't currently offer a way to model information on the payment mechanism or the type of contract.

Modelling for contractual arrangements is discussed in #254.

Payment mechanism

The PPP Knowledge Lab Reference Guide explains that:

The private party can be paid by collecting fees from service users, by the government, or by a combination of the two

So this would suggest a project-level paymentMechanism array, e.g.

{
  "paymentMechanism": ["government", "user]
}

[jpmckinney]

For the payment mechanism, it seems related to https://extensions.open-contracting.org/en/extensions/charges/master/ and https://extensions.open-contracting.org/en/extensions/tariffs/master/ which uses paidBy to indicate 'government' or 'user'.

For the arrangement type, that seems to be the same subject as open-contracting/standard#1144

[duncandewhurst]

For the payment mechanism, it seems related to https://extensions.open-contracting.org/en/extensions/charges/master/ and https://extensions.open-contracting.org/en/extensions/tariffs/master/ which uses paidBy to indicate 'government' or 'user'.

The tariffs extension is for user charges only.

The charges extension is for recording the financial values of the charges applied to users or government. Reusing it to represent the payment mechanism for the project is possible:

{
  "charges": [
    {
      "id": "1",
      "paidBy": "user"
    },
    {
      "id": "2",
      "paidBy": "government"
    }
  ]
}

However, for the use case of identifying the payment mechanism for a project, I'm not sure what the value add is over just using a paymentMechanism string array.

For the arrangement type, that seems to be the same subject as open-contracting/standard#1144

Agreed. OC4IDS and OCDS can use the same approach. Do you have a view on how best to model it?

[jpmckinney]

I assume we will discover more information about payments that can be disclosed, beyond just the mechanism. In that case, an object is better than a string.

The PPP Knowledge Lab Reference Guide is suggestive as to what other facts might be disclosed, e.g. not just who pays (user, government or both) but what they are paying (a particular toll or tariff, a complementary payment to subsidize low-income users, other subsidies), any conditions, etc. We don't need to model these now, but it's better to adopt a structure that allows for such expansion in the future.

[duncandewhurst]

My thinking was that OC4IDS could include the summary field (which relates to the project planning and seems likely to be something users might want to filter projects on) and then the existing OCDS for PPPs extensions could be used to provide the details (which relate to the specific contract in which the charges, tariffs or subsidies are specified).

[jpmckinney]

We presently have one system that has very simple information (with respect to this issue), and we have guidance that suggests that more complex information is possible. It'd be good to check whether other systems provide additional information at the project/summary level, or if they are all similarly simple - before committing a field to the schema.

[duncandewhurst]

Regarding the payment mechanism, ANZIP has a Funding Contributions contributions field which has the following possible values:

• User charges
• Commonwealth Government
• NSW Government
• ACT Government
• VIC Government
• QLD Government
• SA Government
• WA Government
• NT Government
• TAS Government
• NZ Government
• Singapore Government
• Auckland Council
• Brisbane City Council
• Local Council
• City of Sydney Council
• City of Melbourne Council
• Gold Coast City Council

[jpmckinney]

Let's maybe split the issue in two, as I think it will get confusing talking about payment mechanisms and arrangement types in the same issue.

[duncandewhurst]

Done!