Register your interest in joining IATI’s Consultation to inform new guidance on how to publish IATI data that enables traceability.

 

Why is traceability important?

Being able to trace the flow of development and humanitarian funds is critical for understanding complex delivery chains and assessing whether resources are actually reaching intended beneficiaries. While it is currently possible within the IATI Standard to publish data that enables this traceability, IATI does not have a consolidated guidance for publishers on how best to use the IATI standard to ensure traceability. Not having clear guidance also makes it difficult for users to use and analyse IATI data, for instance ensuring that resources are not double counted when conducting analysis.

Consultation launch: Wednesday 31 March 

Building on prior work on traceability, the IATI Secretariat is launching a consultation to inform new guidance on how to publish data using the IATI Standard, that  allows you to trace the flow of funds throughout the delivery chain of published data. We invite the IATI community to take part in this consultation by reviewing the draft guidance, providing inputs, and joining an upcoming webinar to discuss the draft. This consultation is open to all in the IATI community and we particularly invite data users to join  the conversation so that the guidance that results would lead to the kind of traceability that data users need in their data. 

How to get involved

Please take note of the following dates for your calendar:

Date

Action point

31 March

  • Draft guidance and link to feedback form will be posted in IATI Connect; Click on "Follow" to confirm your interest in joining the consultation and receive updates when they are posted. 
  • Discuss and exchange with other Community members through IATI Connect up to 21 April. 

21 April  

  • Submit inputs using the feedback form;

28 April  

  •  Join webinar with the IATI Technical Team  to address feedback received. Register here;

 

Please forward details of the IATI Standard traceability guidance consultation to interested colleagues in your networks. For any questions, do get in touch at support@iatistandard.org or post a response to this thread via the comment-box below. 

Comments (48)

Evgenia Tyurina
Evgenia Tyurina

Hi Andy Lulham

Thank you very much for checking this and letting us know!

Hi Srini Konuganti  , could you please have a look at this? Thank you

 

IATI Technical Team
IATI Technical Team Moderator

Hi everyone!

Please find the draft IATI Traceability guidance and feedback form for you to review, submit your inputs and share feedback by 21 April 2021.

Please also register for the webinar on the 28 April. During the webinar on April 28 the Secretariat will set out clear context, consequences and implications for each of the questions. Participants will be able to discuss further so that they have a sense of what each approach means for different stakeholders (whether publishers, user or both). After the webinar, the Secretariat will update the guidance based on new inputs, and again circulate this throughout the community to confirm the final guidance.

If you have any questions, please feel free to respond to this thread or email support@iatistandard.org and we will get back to you!

We look forward to hearing from you!

 

Mark Brough
Mark Brough

Thanks a lot for the invitation to participate in this consultation, IATI Technical Team  !

 

One issue that I wanted to raise as a discussion here: I find the suggestion of aggregating data by month problematic ("Smaller transactions with the same external funder or external recipient can be aggregated, IATI recommends aggregating per month.") I think we need to discuss this, as a larger point aside from this guidance.

I have seen quite a lot of aggregation from some publishers, in a way that makes the data very difficult to use. Some publishers aggregate by year, which makes it impossible to know even how much was spent in a particular quarter or fiscal year (if the country fiscal year does not align with the publisher fiscal year); a few publishers even aggregate into a single amount for the whole lifetime of the project.

I think IATI publishers should disaggregate their data as much as possible. Monthly aggregation is clearly less problematic than annual aggregation. However, there are a number of use cases that can (depending on the publisher, currency, and other factors) be made much more difficult or impossible even by monthly aggregation. For example:

  • anything where precise currency conversion is required - such as debt management (e.g. loans can be signed in one currency and disbursed in another, so knowing the specific date of disbursement will make a difference to the value in the signed currency), or AidHedge;
  • if there is a future desire to link transactions published by a provider to transactions published by a receiver (which seems to be expressed in this guidance).

Each publisher will have specific reasons why they cannot publish more granular transactions, normally in line with their own freedom of information legislation or policies. That's fine -- but I don't think it is sensible or helpful to create a common low bar across all publishers. The importance of publishing more or less granular data will probably vary between publishers depending on the use case (again I think it is more important for loans and possibly less important for grants).

Finally, in a practical sense, I have seen aggregation done in IATI data in very problematic ways that end up losing a lot of information or making the data unusable. I think it would be good to discourage this practice unless / until we have clarity on when and how this could be done sensibly, and a better understanding of the impact of doing this on specific use cases.

Herman van Loon
Herman van Loon

Hi Mark, fully agree with this. Publish what you do. Transactions always take place on a specific moment in time, and therefore should be published as specific as possible. Aggregating transactions would make IATI data unusable e.g. for processing is systems like FTS, where incoming funds need to be matched with the outgoing flows from publishers.

leo stolk
leo stolk

Hi Mark 

I support the argument to publish transactions as granular as possible, especially when concerning disbursements. Where I support monthly aggregation is for expenditures, our data set would explode in size if we include one on one each expenditure booking without adding information value (like detailed taxi costs, tickets, purchases of office material). Also expenditure could be recognizable as individual salaries. Hence Oxfam Novib opted for monthly aggregations for both disbursements (normally do not happen more than once a month at activity level) and expenditures. 

Leo

Steven Flower
Steven Flower

I fully support the fact that aggregation decisions for transactions has no place in this specific guidance document.  

From a guidance Single Source of Truth perspective it is very problematic to have this *mentioned* within the context of traceability.  As Mark Brough  highlights, there are a wide range of possibilities and considerations, that need to be detailed specifically.  Should such guidance be produced, this would counter the guidance given here: it creates content management and version control headaches and overheads we don't collectively need.

Melinda Cuzner
Melinda Cuzner

Still... it is a real issue that not all can publish every transaction. Sida has found, for example, that it isn't possible to distinguish re-allocation of disbursements from actual transactions. I guess many have similar experiences. And if a publisher has these issues, how are they going to get advice on pragmatic solutions? Then we will come down to every publisher finding their own solution, and/or the advice given will be depending on who gives it. Best practise, yes it should be clear what best practise is, but next-best practise... does that not have a place here at all? 

Steven Flower
Steven Flower

Melinda Cuzner  I agree/understand.  I just don't think it's practical to embed a discussion about best practice on aggregation within the context of guidance on traceability.    Let's have a new guidance document on the roadmap, so we can clearly focus on it collectively...

Melinda Cuzner
Melinda Cuzner

The devil's in the details... I have questions that are in a document I will email to Support but I have also summed them up in the feedback form. But in general very useful guidelines!

I have a conflicting meeting the 28th but trust the webinar will be recorded? 

Petya Kangalova
Petya Kangalova Moderator

Mark Brough   and Herman van Loon   thank you very much for the specific comments on aggregation, which we will take on board for the guidance and suggest an amendment in the guidance doc. This specific sentence on aggregation is exactly what we wanted to seek feedback from the community. You both bring valid arguments and use cases as to why aggregation would not be helpful and will make the data unusable. Will be great to hear from others during the webinar as well.

As you mention I do think a more detailed discussion that goes beyond the traceability guidance on this topic will be really useful to start in the Publishing CoP.

Melinda Cuzner  thank you for submitting your response! Yes, the webinar will be recording and we will share with the community.

Steven Flower
Steven Flower

I'm reading the document currently, and intending to provide feedback

Before I do so - I have to comment that the system of a "read only" google document, into which I cannot add comments (nor see what others think/have suggested) is rather cumbersome.

I absolutely want to know what other people are thinking and saying about this document (thankfully there is some indication of that in this thread). To privatise this into a form seems a real wasted opportunity.

I have limited time to give feedback.  I now have no understanding of what my trusted colleagues in the IATI community think, or have said.  Hence, I have to decide if I should not write lengthy feedback on every aspect, or risk the chance that Herman van Loon  has already covered it :)  Having an document with open comments would have short-circuited this, and got us to the real focal points far quicker.

Of course, if people want to give feedback privately, then that should also be supported.  But for many of us, IATI is a public good.  To remove public and open discourse from the document we are reading is counter to collaboration and productivity. 

Steven Flower
Steven Flower

Pelle Aardema  we seem to have a group of people very willing to work on this issue.  I do believe that was one reason members' agreed to the idea of IATI Working Groups.  I'm confused as to why such crucial issues as traceability guidance are not therefore entrusted to the Working Group mechanism....

Steven Flower
Steven Flower

Thank you to the IATI Technical Team  for drafting and providing this document.  Very useful.

I feel there's something that's *missing* from the document, although understandable, as this is not a part of the standard: it is NOT possible to link together IATI transactions. 

It could be really useful to make that clear to readers early on, I think.  The case study suggests the two £500 transactions are connected - but the specific mechanism to connect transactions is not within the IATI standard.  It's just worth getting that established very quickly - and describing specifically how linkages work within the IATI standard

Background : a thread in Discuss on transaction-transaction linkages

Such a complicated concept may also benefit from some diagrams or visuals, too.  Here's an example Sarah Johns and I worked on, to support organisations with the concepts of IATI traceability.  Hopefully the community can build on this (and please critique it!)

In terms of the document, I flagged:

> Where possible, the value and date of an incoming fund transaction should match the value and date for the outgoing fund transaction in the provider’s activity.

I don't think this is too practical or helpful.  Of course, it makes *sense*, but there are many many cases where this isn't practical or possible (esp in terms of currency changes).  Again, this takes us back to the lack of transaction-transaction linkage in the IATI standard.  If this aspect is included as a proxy to assist users to connect transactions, then that feels to be against what the standard actually provides.

 

Pelle Aardema
Pelle Aardema

Thanks for this, Steven.

I have also provided feedback on the bit about matching transaction dates and amounts.

I think in reality there are multiple cases where transaction dates and amounts may differ between provider and receiver.

I.m.o. the transactions published, should reflect reality (as much as possible):
- Dates may differ because of bank processing delays, registration delays etc.
- Amounts may differ because of currency conversion, bank costs, overhead fees automatically deducted,...
- And I've seen cases where one  transaction is used to fund multiple receiving activities

In the end, we're trying to link activities together, by using a very specific element: the transactions which are part of the activity.
Any visualisation that can make that concept clear, is much appreciated. (now diving into your presentation)

 

 

Herman van Loon
Herman van Loon

Maybe it is better to rephrase "Where possible, the value and date of an incoming fund transaction should match the value and date for the outgoing fund transaction in the provider’s activity." to

"The date of the outgoing transaction should reflect the actual  date the transaction takes place from the viewpoint of the transaction provider. The date of the incoming transaction should reflect the actual date the transaction is received from the viewpoint of the transaction receiver"

There might be a difference between those dates because the time it takes for the banking system to process these transactions. In the new definition IATI reflect reality and does not try to construct (with a lot of effort and communication between the transaction provider and receiver) an artificial reality. We should accept that IATI was never designed as a financial accounting system.

Melinda Cuzner
Melinda Cuzner

Pelle Aardema  Yes, I also brought this up. Not to mention when there are costs included for administrative purposes. I mean, a little part of the cookie is lost along the way, everyone who handles it takes a bite. Of course users are concerned that no on takes too big of a bite, or replaces the chocolate cookie with a raisin cookie. But I don't see how this is going to be easily identified by solely looking at transactions. 

Steven Flower
Steven Flower

Pelle Aardema  Melinda Cuzner  Herman van Loon  Custard Cremes!

Anyway!  I can't help but think the issue on values/dates matching is a distraction from the core focus on traceability.  As discussed, it really doen't matter , as transaction-transaction linkages is not in scope.  

I would therefore advise that reference to the transaction values/dates matching is removed from the document.

Steven Flower
Steven Flower

Two other points:

1. Consistency of language with the IATI standard

> Each transaction should only have one funder and one receiver.

I think it best to stick with the language of the standard: provider and receiver.  The term "funder" is particular, and might not apply to all use cases or transaction types.  Best to avoid people thinking this need not apply to their situation.

 

2. Describing "yourself" in transactions

This is something I mentioned briefly at the VCE.  In transactions, when your organisation is also the reporting-org, is there a need to then make that same declaration within subsequent transactions (whether it be provider or receiver)?  I'd heard various opinions around the community on this, and it would be useful to elicit more.  

From my perspective as a "data user", it can actually be useful to have this information stated in each transaction.  This then means that a transaction could be be used atomically - without the overhead to fetch this data from elsewhere in the activity (and perhaps understand the context).

Of course, others will disagree and suggest this adds bloat to the data, and such a process can easily be handled by efficient scripts and services.  I'm sure that's true too - would be good to hear!

 

3. Validation of activity identifiers

It seems essential that if publishers cite third party activity identifiers, then there needs to be way to somehow validate those.  I've made a proposal on Code4IATI around this, as it seems quite possible.  

I would welcome if the IATI Secretariat  could consider this service.  We need to know if an IATI activity that is provided for traceability actually exists - and such a service would be very welcome to those that supply tools and services to the community of publishers and users

Herman van Loon
Herman van Loon

Hi Steven,

Politely disagree at point 2. To add redundancy by stating the provider (yourself) in outgoing transactions and the receiver (yourself) in incoming transactions possibly leads to inconsistencies.  Redundancy in an international data standard should i.m.o. be avoided. Any data that can be derived should not be published. It is the task of the data user (or the system that uses the data) to derive the information if needed for a specific use case.

E.g. when the IATI community thinks this information is convenient to have in all transactions, it could be derived in the semantic data-layer of the data store. But not part of the IATI standard or guidance itself.

 

Regarding point 3: I fully agree.  Since network transparency is an important item on IATI's strategic agenda, validating the correctness of references, especially references to other activities, is key. I.m.o. this must be part of the IATI data validator and it should be developed as soon as possible, because it would enormously help to improve the data quality with regards to traceability and network transparency.

Pelle Aardema
Pelle Aardema

Regarding 2: Describing "yourself" in transactions

You're probably aware that from my perspective:

  • incoming transactions only need provider information. The receiver is clearly the activity the transaction belongs to.
  • outgoing transaction only need receiver information. The provider is clearly the activity the transaction belongs to.

I.m.o this also means that the 'missing' data doesn't have to be found elsewhere "in the activity". It is the activity, defined by its activity-id: the single globally unique key you use to tie this transaction to any other element of data.

Asking organisations to publish their own activity-id in transactions, in practice leads to unnecessary work (it doesn't add any relevant information) and to all kinds of errors:

  • How would you interpret an incoming transaction, where the receiver-activity-id is different from the activity-id it is published under?
  • Not to mention the cases where implementing organisations publish the back-donor as the provider on their own expenditures.

Re 3:

Yes, there needs to be a way to validate existing IATI activity identifiers. I know Herman van Loon has also flagged this as a requirement for the IATI data validator.

Steven Flower
Steven Flower

Update on 

3. Validation of activity identifiers

Huge thanks to Andy Lulham  & others via code4IATI in building an activity identifier checkerhttps://activity-id-checker.codeforiati.org/

Right now, you can check activity identifiers individually - it is super fast and easy - and really helpful

We'll think further in terms of programmatic checking of batches of identifiers - but it's fantastic to have something to use just a few days after proposing the idea.

 

Herman van Loon
Herman van Loon

Great work Steven! This functionality should definitely also be part of the IATI core since it is critical for network transparency. The logical place to add would be the IATI Data validator i.m.o.

Steven Flower
Steven Flower

I thought of one other thing!

It appears that the guidance does not suggest traceability should be top-down or down-up.  That's a good thing, in my opinion - as models of implementation can vary.

I raise this because we know of rationales such as the Netherlands MFA, who advocate that traceability works upwards (eg: implementing orgs link their activities "up" to donor activities).  The reasons for this (that the donor does not know the partner activity-id at the time of publication) are very practical - but I support this guidance in not stating a preference, to accommodate different approaches within a core framework.

 

Herman van Loon
Herman van Loon

I would say there is a good reason to choose for the down-up option, besides the practicality of not knowing the receiving activity identifier of the partner to which funds are disbursed. Again it is about avoiding redundancy and inconsistencies: you only need to know the provider activity for each incoming fund transaction in order to construct the whole network of interrelated organisations.

 

Steven Flower
Steven Flower

Thanks Herman van Loon 

 

I think this well illustrates a difference between the *theory* of traceability (ie: what is possible within the IATI standard) and the *practicality* of traceability (ie how can it best be achieved). I'm not sure if this guidance document wants to get into those areas, but there is a real difference in terms of theory vs practice, it seems 

Petya Kangalova
Petya Kangalova Moderator

Hi everyone! Just wanted to thank you for engaging in the consultation via this thread and having some very practical suggestions and feedback.

You can find the submitted responses to date via the feedback from in here.

We will review the feedback and will be able to discuss during the webinar on 28 April and then make any suggested changes to the guidance- please do register if you haven't already.

I would also encourage others who are following this thread to share their views!

If you need a few more days, you can still fill in the feedback form or share your views in this thread!

Petya Kangalova
Petya Kangalova Moderator

Thanks to everyone who has participated so far! We have now revised the guidance and have incorporated all your suggestions, following feedback and webinar discussions.

Please see the updated guidance in this document. We have highlighted in yellow the new and updated sections and also provided a summary of changes for reference (see below).

We’d like to ask that you review the updated guidance and add any comments directly into the guidance document or by responding to this thread on IATI Connect.  We also specifically ask for suggestions on examples and visualisations.

Please review and provide comments by Tuesday 25 May. We will aim to be responding to comments during this two week period so that after the deadline the guidance can be finalised and then added to the IATI website.

If anyone would like to discuss further any of the points, we will also be happy to schedule a call. Please let us know if you have any questions by responding to this thread, or emailing support@iatistandard.org! Thanks you very much in advance!

Summary of changes:

  • We have made consistent use of Organisation identifier, IATI activity identifier and provider and receiver organisation (not referencing funder).
  • We have referenced that traceability is not just about financial data and we welcome the additional discussion on Connect.
  • We have not referred to minimum requirements anywhere in relation to the level of detail to be included for participating organisations as well as provider and receiver organisations. 
  • We recognise that “Organisation role” definitions can be strengthened, but that can only happen at a major upgrade (v3). In the meantime, we would welcome adding more examples.
  • We have removed the specific reference that expenditures don’t require receiver organisation, as this can be useful information.
  • We have added a table with transactions and inclusion of provider and receiver org for each transaction type.
  • We have corrected the error where role was included for provider or receiver org.
  • Organisation identifiers: as discussed, we suggest we create a separate page on the IATI website and link to the traceability guidance and also creating identifiers guidance.
  • In the enhanced traceability section we have:
    • Removed the reference to aggregation: “ Smaller transactions with the same external funder or external recipient can be aggregated, IATI recommends aggregating per month.”
    • Removed reference to donor guidance: “ The exception to this is if your donor requires you to report core funding. Please refer to your donor’s guidance.”
    • Removed the sentence “Where possible, the value and date of an incoming fund transaction should match the value and date for the outgoing fund transaction in the provider’s activity.” as there was disagreement on it.
    • We have added a sentence saying that disaggregating transactions enables traceability as suggested in the webinar.
  • Examples and visuals:
    • We ask that you share examples in this thread that we can add to the participating organisation role examples and the examples section of the guidance.
    • We have linked at the end to any external sites with visualisations on traceability and would welcome more examples.
Petya Kangalova
Petya Kangalova Moderator

Thank you to everyone who reviewed the updated guidance and added comments! I have now reviewed, responded and incorporated changes where relevant. We will use this document as the final version that we will add to the IATI website in June.  Once the guidance has been added to the website we will share a link here.