Project-level disbursement records (planned and actual)

[duncandewhurst]

The CoST IDS/OC4IDS review proposes the following data point in the climate finance extension:

Disbursement records: Disbursements dates according to financial agreement versus actual disbursements dates [value, currency, date].

Where disbursements refers to monies received by the project, rather than paid out from the project to contractors (those were already implemented in #273).

Based on the research in open-contracting/ocds-extensions#209, project financing flows typically look like this:

flowchart TD
  A["Funding source
    e.g. GCF"]-- "'Parent' loan
                  agreement" -->
  B["Financing party
    e.g. UNDP"]-- "Sub-loan
                   agreement" -->
  C["Project 1"] &  D["Project 2"] & E["Project 3"]

Loading

Presumably, the disbursements that are of interest are related to the sub-loans since those are specific to the individual infrastructure projects. @EvelynDinora, please correct me if I'm wrong.

According to Denton's Guide to Project Finance, whilst the sub-loan agreement is between the financing party and the project company, significant disbursements are usually made directly from the financing party to suppliers, rather than via the project company:

It will usually be the case that all disbursements of the loan for construction-related payments (and indeed other significant items) will be channelled directly through the facility agent to the relevant payees. The lenders will not usually be prepared to release drawdowns direct to the project company and take the risk that these monies are not disbursed by the project company.

For example:

flowchart TD
  B["Financing party
    e.g. UNDP"]-- "Sub-loan
                   agreement" -->
  C["Project"]
  C -- "Contract" --> D["Supplier
                        e.g. Skanska AB"]
  B -. Disbursements .-> D

Loading

In which case, those disbursements can be modelled in the relevant contracting process's .transactions array (in keeping with the mapping for the existing 'disbursement records' element in the reactive disclosure section of the CoST IDS):

{
  "contractingProcesses": [
    {
      "id": "1",
      "summary": {
        "transactions": [
          {
            "id": "1",
            "payer": {
              "id": "1",
              "name": "United Nations Development Programme"
            },
            "payee": {
              "id": "2",
              "name": "Skanska AB"
            },
            "date": "2024-01-01T00:00:00Z",
            "value": {
              "amount": 10000000,
              "currency": "USD"
            }
          }
        ]
      }
    }
  ]
}

However, this leaves two gaps when compared to the proposed data point:

1. How to model actual disbursements which are made directly to the project, independently of a specific contract
2. How to the model planned disbursements (the .transactions array is only for actual payments)

I propose:

1. Adding a project-level .transactions array.
2. Reusing OCDS 1.2's approach to modelling planned payments as milestones. This would involve adding a .milestones array at project-level (already discussed in Add a project-level milestones array #253) and at contracting process level.

[duncandewhurst]

@EvelynDinora, @mgraca-prado, @jpmckinney it would be great to get your feedback on this proposal, please.

[jpmckinney]

Sounds fine. We just need to be very clear in the field descriptions when each transactions array should be used. This is one of the few cases where referring to another field in the schema is necessary :)

[duncandewhurst]

Background

I did some more reading about South Africa's Water Reuse Programme (WRP) to make sure that the proposal in this issue is sufficient to model different ownership arrangements and procurement strategies.

According to page 65 of the approved funding proposal, infrastructure projects under the program can be either be publicly owned or owned by a public private partnership (PPP):

Ownership: The ownership model will be either a local government authority (municipality) or special purpose vehicle (SPV) – the latter comprising municipalities, the private sector, and/or possibly a national government entity (depending on size).

Publicly owned

The following diagram shows financing arrangements and contracts for a publicly owned infrastructure project. Mappings to OC4IDS roles and fields are provided in brackets:

flowchart TD
  0["DBSA
     ('funder')"]
  1["Municipality
     ('publicAuthority', 'buyer')"]
  2["Private company
     ('supplier')"]

  0-- "Loan
       (`budget.finance`)" ---1
  1-- "Construction contract
       (`contractingProcesses`)" ---2

Loading

The proposal is sufficient to model the different transactions that might occur in a publicly owned infrastructure project:

flowchart TD
  0["DBSA
     ('funder')"]
  1["Municipality
     ('publicAuthority', 'buyer')"]
  2["Private company
     ('supplier')"]

  0-- "Disbursement
       (`transactions`)" -->1
  1-- "Disbursement
       (`contractingProcesses.transactions`)" -->2
  0-- "Disbursement
       (`contractingProcesses.transactions`)" -->2

Loading

PPP

The following diagram shows the financing arrangements and contracts for a public private partnership. There are two layers of contracts for a PPP: the PPP contract awarded to the project company / SPV (see page 49 of the approved funding proposal) and sub-contracts signed between the SPV and third-party contractors (e.g. the construction contract and the operation/maintenance contract) (Source). My understanding is that only the PPP contract is in scope for OC4IDS:

Key:
--- = out of scope for OC4IDS

flowchart TD
  0["DBSA
     ('funder')"]  
  4["Municipality
    ('publicAuthority', 'buyer')"]
  5["Project company / SPV
     ('supplier')"]
  6["Private company
     (n/a)"]:::oos

  0-- "Loan
       (contractingProcesses.summary.finance)" ---5
  4-- "PPP contract
       (`contractingProcesses`)" ---5
  5-. "Construction contract
       (n/a)" .-6

  classDef oos fill:GhostWhite,stroke:Gray,stroke-dasharray:3

Loading

In this scenario, I think that disbursements from the project company / SPV to its sub-contractors are out of scope and all other disbursements belong in contractingProcesses.transactions.

As mentioned in the issue description, significant disbursements are usually made from the funder directly to the subcontractor, rather than going via the project company, so there is a potential gap around the project company's sub-contractors not otherwise being modelled in OC4IDS, but I suppose that can be covered in the mapping guidance (e.g. "If the disbursement is made directly to a sub-contractor of the project company, add the subcontractor to the parties array.")

flowchart TD
  0["DBSA
     ('funder')"]  
  4["Municipality
    ('publicAuthority', 'buyer')"]
  5["Project company / SPV
     ('supplier')"]
  6["Private company
     (n/a)"]:::oos

  0-- "Disbursement
       (`contractingProcesses.transactions`)" ---6
  0-- "Disbursement
       (`contractingProcesses.transactions`)" ---5
  4-- "Disbursement
       (`contractingProcesses.transactions`)" ---5
  5-. "Disbursement
       (n/a)" .-6
  
  classDef oos fill:GhostWhite,stroke:Gray,stroke-dasharray:5

Loading

Proposal

Schema changes

Path	Title	Description	Type (format)	Codelist	Change
transactions	Transactions	Financial transactions related to this project. For example, a disbursement from a funder to the project company. Transactions related to a contracting process, like a disbursement from a funder to a supplier, should be recorded in the contracting process summary's .transactions.	Array of Transaction objects		New field
Transaction	Transaction	A spendingfinancial transaction related to thea project or contracting process. Draws upon the data models of the Fiscal Data Package and the International Aid Transparency Initiative and should be used to cross-reference to more detailed information held using a Fiscal Data Package, IATI file, or to provide enough information to allow a user to manually or automatically cross-reference with some other published source of transactional spending data.	Object		Description
milestones	Milestones	Milestones associated with this project.	Array of Milestone objects		New field
ContractingProcessSummary.milestones	Milestones	Milestones associated with this contracting process.	Array of Milestone objects		New field
Milestone	Milestone	The milestone block can be used to represent a wide variety of An events in the lifetime of a project or contracting (or planning) process.			Description. Otherwise, copied from OCDS 1.2 Milestone definition.
Milestone.id	ID	A local identifier for this milestone, unique within this block. This field is used to keep track of multiple revisions of a milestone through the compilation from release to record mechanism. Although an integer is allowed, it is recommended to use a string.	String		Description and type. Otherwise, copied from OCDS 1.2.
Milestone.code	Milestone code	Milestone codes can be used to track specific events that take place for a particular kind of project or contracting (or planning) process. For example, a code of 'approvalLetter' can be used to allow applications to understand this milestone represents the date an approvalLetter is due or signed.	String		Description. Otherwise, copied from OCDS 1.2.

Codelist changes

milestoneType (new)

Adapted from OCDS 1.2:

Code	Title	Description	Change from OCDS 1.2
preProcurement	Pre-procurement milestones	For events during the planning process, such as the preparation of key studies.	None
approval	Approval milestones	For events such as the sign-off of a contract or project.	None
engagement	Engagement milestones	For engagement milestones, such as a public hearing.	None
assessment	Assessment milestones	For assessment and adjudication milestones, such as the meeting date of a committee.	None
delivery	Delivery milestones	For delivery milestones, such as the date when a good or service is to be provided.	None
reporting	Reporting milestone	For reporting milestones, such as when key reports are to be provided.	None
financing	Financing milestones	For events related to the funding of the project or contracting process. In public-private partnerships, such events might include, for example, planned payments and equity transfers.	Description
payment	Payment milestones	For payment milestones, such as the date when a payment is expected to be made to a supplier. If the status of a contract's project or contracting process's payment milestone is 'met', then the project or contracting process ought to have an entry for the payment under its implementation.transactions .transcations.	Description
procurement	Procurement	For events taking place during the procurement that are not captured elsewhere, such as additional enquiry periods or draft bid submissions in a competitive dialogue process.	None
contractClose	Commercial and financial close	For events relating to agreeing commercial issues between the parties to a public-private partnership contract, executing contract documentation, and meeting any pre-conditions relating to the project's financing.	None
securityClearanceDeadline	Security clearance deadline	The tenderers can obtain their security clearance until this date.	None

milestoneStatus (new)

Copy from OCDS 1.2 milestoneStatus codelist with no changes.

Example

Publicly owned

The following example shows a publicy-owned project with two disbursements, one made to the project owner and one made directly to a supplier.

{
  "transactions": [
    {
      "id": "1",
      "payer": {
        "id": "1",
        "name": "United Nations Development Programme"
      },
      "payee": {
        "id": "2",
        "name": "Municipality A"
      },
      "date": "2023-07-01T00:00:00Z",
      "value": {
        "amount": 5000000,
        "currency": "USD"
      }
    }
  ],
  "contractingProcesses": [
    {
      "id": "1",
      "summary": {
        "transactions": [
          {
            "id": "1",
            "payer": {
              "id": "1",
              "name": "United Nations Development Programme"
            },
            "payee": {
              "id": "2",
              "name": "Skanska AB"
            },
            "date": "2024-01-01T00:00:00Z",
            "value": {
              "amount": 10000000,
              "currency": "USD"
            }
          }
        ]
      }
    }
  ]
}

PPP

The following examples shows a PPP project with two transactions. One made to the project company / SPV and one made directly to a subcontractor.

{
  "contractingProcesses": [
    {
      "id": "1",
      "summary": {
        "transactions": [
          {
            "id": "1",
            "payer": {
              "id": "1",
              "name": "United Nations Development Programme"
            },
            "payee": {
              "id": "2",
              "name": "Project SPV"
            },
            "date": "2024-01-01T00:00:00Z",
            "value": {
              "amount": 10000000,
              "currency": "USD"
            }
          },
          {
            "id": "1",
            "payer": {
              "id": "1",
              "name": "United Nations Development Programme"
            },
            "payee": {
              "id": "3",
              "name": "Subcontractor B"
            },
            "date": "2023-07-01T00:00:00Z",
            "value": {
              "amount": 5000000,
              "currency": "USD"
            }
          } 
        ]
      }
    }
  ]
}

[EvelynDinora]

@duncandewhurst yes, the disbursements that are of interest are related to the sub-loans since those are specific to the individual infrastructure projects. I am happy with the proposal for both public owned and PPPs and having the array associated to the project and the contracts.

[duncandewhurst]

Thanks, Evelyn!

@jpmckinney are you happy with the proposal in my previous comment?

[jpmckinney]

Yes, looks good. Just procuremen -> procurement

[duncandewhurst]

Thanks. I've corrected the typo.