Tech Paper: Improvements to the Activity Standard

Standard Management 2.03 Decimal Upgrade Discussions
#1

This paper will consider a number of issues relating to the Activity Standard. (We may need to split this paper in two to make it more manageable.)

Secondary publishers

  • The definition of what constitutes a secondary publisher requires clarification.
  • Organisations reported by secondary publishers that do not themselves publish to IATI should be flagged so that their activity data can be used without fear of duplication or double counting.
  • Does there need to be a way to link the activities of an organisation reported by a secondary publisher to a primary publisher?

Future-dated transactions

  • Current rules insist that transactions are a record of de facto actions that must therefore take place in the past. This logic is used to detect when a publisher’s data has changed to calculate timeliness (publisher statistics logic looks for a change in the most recent transaction date). There are however business models where accounting systems legitimately issue committed instructions to banks for future transactions.

Participating organisation type attribute

  • Add an attribute to participating-org - particularly useful for describing implementing organisations
  • Agree on either separation or alignment of the IATI Organisation Type codelist with the CRS Channel of Delivery. (See discussions here and here.)

Results aggregation/disaggregation

Transaction Issues

  • Add a transaction type code for internally sourced / core funds. (See separate paper on core funding)
  • Change transaction type code description “Interest Repayment” to “Interest Payment”
  • Make value-date mandatory (if agreed this would go in to the 3.01 queue)
  • Proposal to specify an explicit exchange rate for a transaction

Budget Identifier

  • Deprecate BudgetIdentifier codelist as it has been superceded by the new list of CRS purpose codes
  • Modify the BudgetIdenifierVocabulary codelist. (See discussion here.)

Total Estimated Cost

  • Proposal to add a new total estimated cost element. (See discussion here)
  • Review and clarify definitions for commitments, budgets and costs

Miscellaneous

  • Review ambiguous use of @type and @code attributes across schema
  • Limit use of description/@type within an activity. (i.e. don’t allow repetition of same @type in one description)
  • [Make URLs on elements with a publisher-provided codelist mandatory](http://Make URLs on elements with a publisher-provided codelist mandatory)

This paper is part of the Agenda for the IATI TAG 2016 Technical Consultation Workshop

:bird: #IATI #TAG2016

Tech Paper: Improvements to the Organisation Standard
Does Commitment need to be renamed to "Outgoing Commitment"?
A total-budget for an activity?
Standards Day: Outline Agenda
#2

Participating organisation: include contact-info block

An issue we explored via the Initiative for Open Ag Funding was around identification and clarification of participating-orgs. Granted, a unique / common @ref is an established method to do this. However, we also highlight that further detail may be useful, given the fact that most organisations described with IATI are very large and consist of numerous departments and staff. To this end we propose the addition of the contact-info block to the schema, intended for optional inclusion within the participating-org element. This would enable publishers to include specific partner / organisation details within any activity, and may also assist data users to clarify the exact person/department involved in an activity.

#3

Hi Steven. Yes, I remember this discussion - I will make sure this proposal has a section in the paper. Thanks for reminding me!

#4

PIU identification and -reporting.

Realising that PIU’s are here to stay, while recognising that they come in many different types, sizes and shapes, IATI must find a way to include them all - a standaradised way to integrate reporting from PIU’s.

If a PIU is a separate legal entity, then there is no problem - the {RegistrationAgency}-{RegistrationNumber} identification is OK.

If a PIU is merely a subsiduary body of another organisation, it might take two different forms:

  1. Integrated part of the parent-organisation - allowing data to be Integrated into the IATI files of the parent-organisation.

  2. Separated from the parent-organisation - being unable to process data into the consolidated dataset

It is obviously the second form that cause problems. And unless the problem is solved, the parent-organisation can only report disbursement to itself. No details on the further use of the funds are revealed, and this goes for inflows from other sources as well. It is not just a black box, but a black hole. This allows no further work on traceability.

The only way around the problem, within the current standard, is for the parent organisation to double as RegistrationAgency - Thus allowing PIU’s to become reporters. This is hardly desireable, since the concept of Registration Agencies is relying on the assumption that they are the real thing - not just another pile of crap data.

Having a flexible approach to the identification of Unique organisations, we could also allow PIU’s to just declare themselves (without the reference to Registration Agency), or we could set up a IATI-registration-office to serve the purpose. But this is only mentioned to cover the options - it is not to be recommended.

I can only come up with one more option. It is not pretty, but having eliminated the previous I find it must be considered seriously. And I have to include the following proposal under the heading ‘Improvements to the Organisational Standard’ as well.

Adding a suffix to the organisation_identifier of their parent_organisation could single out PIU’s, and allow for validation (ensuring uniqueness of the suffix) if it is required by the parent_organisation to identify their PIU’s in the Organisation_file.

#5

@OJ_ please explain what a PIU is?

#6

Just as a heads up here, we’ve convened a group of M&E specialists to look at the Results element and advise how to improve it, and findings and recommendations will be provided as a paper for the TAG. This is likely to go beyond changes to the aggregation flag, and I’m guessing it will be an iterative process to consult on and incorporate into the Standard - some changes will be appropriate for an integer upgrade and some for a decimal.

#7

Sorry - it’s a ‘Project Implementation Unit’.

#8

@OJ_ are you aware that IATI is partnering with others to improve our approach to all identifier headaches. @TimDavies and team can you get around OJ’s issue?

#9

Thanks @bill_anderson, @OJ_

So - as I understand the issue here, it is a question of identifying sub-units / departments etc. of a legal entity.

Right now, the Organisation Identifier string is supposed to point to a specific legal entity. Where PIUs are not a legal entity, their Organisation Identifier string would be that of their parent legal entity.

The Organisation Identifier strings could be adapted to include a sub-unit component. I’ve opened an issue in the Org ID project here which relates to this, in terms of whether a separator could be declared for a sub-unit component within the identifier string.

This would have implications for tools that are interpreting identifiers, but does not look entirely implausible, providing it makes sense across standards working with the shared organisation ID method.

However, it might be worth checking back on the original traceability issue. Based on the work @stevieflow and Rory Scott have been doing, we’ve found lots of cases of in-organisation traceability, where activity identifiers level traceability can be used to show how funds flow between activities inside the single organisation.

How big an issue would there be with two separate units of the same organisation/legal entity reporting to IATI with the same reporting-org/@ref value, but uploading separately to the registry, and potentially including different strings in the reporting-org/narrative field to indicate which department they are? Or does this not get to the issue that is of concern?

#10

The only rule that stops a publisher passing themselves off as another institution is the unique one-to-one relationship between the registry’s publisher id and the reporting-org/@ref. ** One possibility could be to modify this rule to say the registry publisher id needs to match reporting-org/@ref excluding a distinguishable suffix.

This, I think, gives us three options:

  1. Departments publish to separate registry accounts using different reporting-org/@ref’s
  2. Departments are reflected in the activity identifier, not the reporting-org/@ref. (NB there is nothing stopping a transaction having the same provider-org and reciever-org, but different provider- and receiver- activity ids so funds can be transferred internally between departments and/or activities)
  3. Departments publish (jointly or separately) to 1 registry account using differently suffixed reporting-org/@ref’s

Only the third option requires a change to the standard. This would most probably need to be part of an integer upgrade.

Personally I would not be in favour of using any narrative field for any logical process

** There have been issues with the implementation of this rule. That doesn’t undermine its importance. And we also need to deal with identifying organisations published by secondary publishers who do not publish themselves.

#11

Option 1 should be preferred - but then we are back at the question of how to make a valid workaround and exemption from the current requirement on reporters to be ‘independent legal entities’. Is my proposal too far fetched - requesting the primary reporter to state its own list of valid subsidiary reporters in the org_file?

This could allow a procedure similar to that of activity-identifiers (as elaborated in NL’s guidelines), where the ‘sponsor’ instructs the ‘receiver’ to use a particular key, when fulfilling the reporting requirement. Contrary to independent legal entities, these should not be allowed to proliferate in a bottom-up process.

#12

The draft paper on Improvements to the Activity Standard is now available.

#13

Thanks Bill,

Lots of things I can imagine using a lot here, especially contact info, and aid type (please can this allow percentage splits)?

RE @secondary-unique, I think that it would be good practice to separate the two functions into two flags 1) @secondary - this a secondary publisher and 2) @unique - this data believed to be unique. It might also make it easier to then revoke/ignore/drop the ‘unique’ flag if the primary publisher later publishes or you don’t trust it, but still be able make use of the secondary publisher flag.

I am very worried that @unique will invoke a false sense of security though, blanket acceptance could lead to further double counting so anyone using multi-publisher data will have to do their own checks anyway. E.g. imagine a situation where there were multiple secondary publishers, it would not be as simple as checking if the primary publisher was publishing. It would also be good to figure out how you could tell if the @unique flag was subsequently incorrect. This would depend on being able to match activities across different publishers?

Thanks,

Matt

#14

Would anyone like to have a stab at rendering this idea into a practical proposal?

#15

@bill_anderson what is needed to make this a practical proposal, and what is the deadline?

I had imagined (but without deep thought) that it would be similar to recipient-county but with aid-type instead. Percentages would follow the same rules. I could do a ctrl-f replace, plus a few examples of where this might be useful?

Does anyone else have an opinion on whether this belongs at the activity level or the transaction level? I am not sure how IATI handles these things e.g. if an activity is 80% TA, could a disbursement be set to be 50% TA and 50% something else?

Thanks,

Matt

#16

Here’s a possible alternative approach. If we have a guideline that secondary publishers should (when reporting activities of organisations that publish to IATI themselves) use the same organisation identifier in participating-org/@ref for the secondary activity as the ‘primary’ organisation used for reporting-org/@ref it would be relatively trivial for a utility to check for ‘duplicate’ organisations across the entire IATI corpus.

This, however, raises a problem. An activity reported by a secondary publisher can contain participating-org data on funders, implementers, etc, but nothing tells you who ‘owns’ the activity being reported. Do we need a new @role code?

#17

hi @bill_anderson

I had presumed (perhaps erroneously) that most secondary publishers were just adding something (e.g. aiddata with the split purposecodes, or an organisation who republished with some better geocoding) and therefore not seeing themselves as ‘owners’ in any way. The activities would already have provider-id's and provider-activity-id's.

Your suggestion speaks to a situation where a secondary publisher was publishing an activity that was ‘new to IATI’ and in that case I think that your guideline for the participating-org/@ref is a good one (could also just drop anything where the reporting-org wasn’t in the list of participating-org, plus it supports the use of existing IATI components.

As for the @role, I use this a lot in my manual AIMS work but this is just to allow e.g. DfID to have @role=funder and @role=implementer on the same project so we can capture both the funds they pass on, and those they administer themselves. Basically a guide for humans who can’t work this out based on reading the transactions. Not a problem for IATI.

I am less sure that we need to know who ‘owns’ it but may have misunderstood your problem. We know who reported it, and who is involved already. What would we do with ‘ownership’ - is there a level of additional responsibility that we expect from them? Again, in AIMS ‘ownership’ typically defines who can edit the activity - but moving away from this (broken) model is one of my favourite things about IATI.