Add related-transaction element (excluded 2.03)

Standard Management 2.03 Decimal Upgrade Proposals
,
#1

This proposal is part of the 2.03 upgrade process, please comment by replying below.

Standard
Activity

**Schema Object** iati-activity/transaction/related-reference/@ref

**Type of Change** Schema addition

**Issue** In an activity that involves earmarked funding from more than one funder it is currently not possible to trace the financial flow through the activity. This is of particular relevance to pooled funds. A reference shared between a commitment (or incoming funds transaction) and a disbursement would clarify this.

**Proposal**

  • Add element iati-activity/transaction/related-reference
    • Definition: An internal reference that creates a link between two transactions within a single activity. The value in transaction/related-reference/@ref should be the same as transaction/@ref in another transaction.
    • Occurs: 0..*
  • Add attribute iati-activity/transaction/related-reference/@ref
    • Definition: A value that matches the value in transaction/@ref in another transaction.
    • Occurs: 1..1
**Standards Day** This was a late presentation - part of a group of proposals that will improve humanitarian use of the standard - and was not discussed.

**Links** N/A

Version 2.03 Decimal Upgrade - Index of Proposals
#2

I am a bit doubtful about this proposal since the origin of the money is by definition lost in pooled funding. So if you want to be able to track the financial flows for each funder, you shouldn’t use pooled funding at all. Instead make a separate activity for each funder.

Are there any real world examples where a fund manager keeps track in the financial system of the actual origin of the money at the time of disbursement?

#3

I agree with Herman. It is a contradiction in terms to intend to trace earmarked transactions within a basket/pooled fund. If it is earmarked, then it can’t be part of the pool.

I would suggest that the problem is better solved by application of NL’s guidance on this Funding model - establishing a parent-activity to hold the incoming, pooled funds and then have the individual activities as children, and thes childrren can then receive additional ‘earmarked’ contributions with no reference to the pool.

One relevant clarification would be for the fund-manager to report the type_of_aid on incoming donor-contributions. It would be highly relevant to make sure that the donor and the fund-manager agrees on the classification of the modality Applied.

#4

Broadly, I agree with the nature of this proposal. It is not possible to link specific activities via the standard. We have a discussion thread on this, which isn’t referenced in this proposal. NB:I’m not convinced we got to consensus in that thread either!

However, I find the cited “issue” of pooled funds is too specific and narrow - and the concerns from @Herman and @OJ_ are well-grounded.

Our point was that in use cases where transactions could - or should - be linked, then the standard simple does not enable this. We have found instances where this would be very useful (see below). However, to reiterate - and perhaps to points made by @rolfkleef et al - this does not encompass a sudden move to make IATI an accounting system!

@rory_scott and I have since explored an extension to illustrate this. This has been driven by our work with @JohnAdams at DFID, looking at traceability - the data is now live, in the use case of a fund manager for DFID.

I think there are plenty of use cases / support for the ability to link transactions, especially in certain aspects of delivery chain mapping / traceability. We found some very interesting needs for this, but - and I repeat (!) - these are not universal, and not about mandating publishers to link each and every activity!

tl;dr : I support the technical proposal, but not the specified use case.

#5

I might get the scent of where you are heading, but I am not able to see it in the example you point out in d-portal. This is just a big grant, allowing disbursements to a very large number of partners. But that points towards an entirely different issue – an issue where I’m quite sure that there will never be consensus about how to use the schema nor the optional hierarchy.

(In our activity-file, the lowest level is the level of ‘commitment’ – not the transaction of course, but the ‘binding agreement with the partner’ meaning that each and every one of the many recipient organisations in the example would constitute a child-activity of it’s own, in DK’s activity file.)

There are also an issue about the ‘role’ of organisations; as a random example in the example I could refer to ‘SOS Sahel’, listed as implementing organisation no. 98. It appears however that this organisation calls itself ‘SOS Sahel International UK’, and claims to hold an extending role, with SOS Sahel Ethiopia as the implementing partner.

So – looking into it in order to understand the motivation for enriched transaction-data, I arrive at entirely different issues. Issues that are probably less about the standard itself, but rather how we use it – how we recommend our partners to use it. In this case: Ensure mutual recognition of the ‘role’ undertaken by your organisation in the specific activity, and make sure that your identification of ‘iati-activities’ corresponds with a very tangible concept of ‘partnership’, already found in the very foundation of your operational procedures.

I know it’s a far shot, but could that last observation be considered an alternative solution to the problem you address? If one activity has multiple sources, and one of these insists to ‘earmark’ their support for specific parts of the activity, then it just might be that you actually already are managing the complex as several separate activities, and ought to revise your definition of IATI-activities rather than the coding of IATI-transactions.?

#6

Hi, we have several concrete use cases for this feature for humanitarian financial tracking.

  1. Traceability: for activities funded by multiple donors, the ability to trace funding from each upstream donor through the activity to its downstream use. This is not the same as a pooled fund - I fully agree with Herman that a genuine pooled fund is by definition not supposed to be able to trace funding through the pool. However, if a regular activity - representing any humanitarian intervention - is funded by several donors, and finances several implementing partners, then without this feature a user cannot add traceability info even if he/she actually has this information. What we are finding with FTS reporting is that there is a proliferation of pseudo-‘pools’ within regular organisations where they report in bulk on income and in bulk on allocations without bothering to make traceable links between the two, claiming that they operate an internal pool when in fact their internal systems do require actual allocation of funding to its use (even if the funding was not earmarked by the donor), and they happily report back to the individual donors on where their money went. I am aware that this situation can be avoided through the use of a parent activity and then multiple child activities, each of which is funded by only one donor - but IATI is designed to support activities having multiple transactions from multiple donors, so enforcing the single-donor single-activity approach seems like the wrong way to approach this. This is not about making IATI more like an accounting system: traceability is a key element of the Grand Bargain and essential for tracking funding to local actors, so IATI should make this as easy as possible.

  2. Accountability: the ability to uniquely link pledges to commitments, and commitments to disbursements. This concerns accountability of donors to their implementing partners and the ability to use IATI to identify gaps between promises made and funding actually received. Again, without this feature this is currently only possible if an activity has a single disbursement or a single pledge, so that the correct association of transactions is obvious. However, it is not uncommon for an activity to be funded by several different commitments from the same donor at different points in time, and for each of those commitments to then have multiple disbursements. FTS aims to maintain a record of how much has been committed vs disbursed. Even more importantly, for resource mobilisation purposes many humanitarians aim to track pledges. With IATI 2.03 expanding to allow for ‘pledge’-type transactions, it is important for both donors and recipients to have easy ways to use IATI to indicate how actual commitments are ‘drawing down’ on pledges made (where this info exists), and then hold donors accountable for outstanding pledges. Again, there are workarounds - for example, limiting an activity to having only one pledge and one commitment from any one organisation - but again in our opinion IATI’s role should be to make this as easy as possible, and this feature would provide an additional tool to aid accountability.

#7

This topic has been included for consideration in the formal 2.03 proposal, subject to additional use-case being illustrated.

#10

Notes from consultation calls w/c 3rd July

The proposal was reviewed by those on the call and there was no objection from the group.

#11

When reading back this topic I noticed that the last question of @OJ_ has not been addressed. I think @OJ_ remark “If one activity has multiple sources, and one of these insists to ‘earmark’ their support for specific parts of the activity, then it just might be that you actually already are managing the complex as several separate activities, and ought to revise your definition of IATI-activities rather than the coding of IATI-transactions.?” makes sense and deserves an answer.

@OJ_: where you in the consultation call and was your question answered?

#12

No, I was not available at the time. I still think that we are adressing the real issue from the wrong angle - we should rather clarify what we expect to be commonly understood as ‘an activity’.

We are misunderstanding each other, and I fear that we are missing an opportunity to clarify different ‘points of measurement’ that could have been valuable. I still don’t see the benefit of linking transactions - I fear it will be a re-invention of the quite harmful notion of ‘follow the money’, now just as an optional alternative to the shared concept of traceability.

#13

I think a generic argument looks like this:

  • An IATI activity can contain many commitments and disbursements from one or more sources
  • Some stakeholders see a benefit in linking particular commitments to particular disbursements.
  • The standard already contains the transaction/@ref attribute
  • Adding an optional transaction/related-reference element that re-uses transaction/@ref would solve this use case without interfering with publishers who don’t use it and users who don’t need it.
#14

On this one I’m not convinced that there is a universal user need for linking specific transactions, although @stevieflow and @ximboden make some specific arguments.

I don’t have any real objection to adding an optional transaction/related-reference element.

However, would we not be better off doing some diagramming of different ways that activities can be related and seeing if a change in how these activities could be represented using the existing elements. I’d like to see more of these “architectural patterns” to inform this discussion.

#15

I fully agree with @OJ_.

1 - We already have the possibility in the standard to track donor funds by defining an activity for each donor for which you want to track.

2- The proposed change will not enable you to properly track donor funding. Let’s take the example that two donors, each disbursing 5 milj. Euro’s for an activity. Subsequently an expenditure of 7 milj. Euro’s from that activity is done. How are you going to attribute these 7 milj. Euro’s to the 2 donors using the transaction references?

3 - Introducing this change will add an (i.m.o. flawed) alternative way to track funds. This will greatly complicate data use when you want to combine data from publishers which use different ways of fund tracking.

Therefore I can not agree with this proposal.

#16

Yes, I think diagramming might help this discussion.

#17

This is very late but, for reasons I won’t go into here, I’ve been effectively off-radar for around two months.

That being said I did make an informal extension for this functionality a while ago, which might help give some further structure to the discussion of this element.

It offers three specific use cases, and examples for implementing them:

  1. associating a disbursement in one organisation’s data with an incoming fund in another’s ('i.e the inter-organisation conception of ‘following the money’).

  2. associating a disbursement in one organisation’s parent-activity with an incoming fund in it’s child activity (following the money within a hierarchical group of activities).

  3. associating a group of small transactions with a single large transaction within a given activity (following the money within an activity - ideal for ‘flat’ representations of a fund-manager’s data for instance).

For the full extension text, see here. I won’t be able to join the call today, but I’m happy to address any questions about the above, and for the record I don’t see any compelling reasons not to include this functionality, assuming that everyone is realistic about the political and pragmatic limits of ‘follow the money’, as well as the technical hurdles.

#18

Following the call to seek consensus on the humanitarian proposals that took place on 5th September 2017 this proposal has NOT been accepted for inclusion as part of v2.03.

Some members of the IATI community felt that the business case for this proposal was not yet strong enough for it to be taken forward at this time.

#19