Dear IATI-Community,

The International Aid Transparency Initiative (IATI) has published a Request for Proposals (RfP) to provide an online IATI data publishing tool.

The publishing tool will enable organisations to publish their data on development and humanitarian activities according to the IATI Standard and convert their files into the XML format required to make the data machine-readable.

Currently IATI does not provide its own publishing tool, and organisations rely on a range of external tools to publish their data or build their own bespoke systems.

The new IATI publishing tool will be free to use and should be simple, intuitive and aligned with the IATI schema and rulesets so there is as little confusion as possible for publishers. It should also make use of the IATI Validator and check the data before publication.

Please see the United Nations Global Marketplace website for all details and note the deadline has been extended until 25 October 2021 to submit a proposal.

Comments (23)


Hi - can the supporting report mentioned in the RfP be shared?

I am worried about the signal this sends to the community e.g. that if anyone invests to make a product that supports the IATI ecosystem and then introduces charges (noting that aidstream does not charge for up to 20 activities) then IATI will launch a free competitor. I think there needs to be a shared statement first of what the community is supplying, where IATI thinks the gaps are, and then to give the community a chance to adapt and fill those gaps before decides IATI monopolises the space. I suspect this solution would be far cheaper in the long-run - the cost to persuade aidstream and similar tools e.g. from D4D and CoVE to add validator integration etc would be far smaller than the cost of IATI developing another new tool. If this kills aidstream - which has been a great product for many users - and surely they cannot be expected to host/run it for free - then the 'cost' of this investment is much much higher than just the development cost.

I think there is a major cost not factored in here e.g. that running a publishing tool has huge support costs to help users - I guess that is why aidstream needed to charge - will IATI be hiring more analysts to take this on - that will be a large long-term expense currently outsourced to 'the community'.

It strikes me as strange, that given all the procurement and management of outsourced development process difficulties expressed in the last 3 years, that the answer here is to launch another big procurement, allowing development in a language that IATI may not already support, not hosted on the new IATI Azure setup, and without a plan past the first year of hosting.....this seems to be counter to many of the lessons that we have been learning - it would be good to at least see the pro/con list for those decisions.

Finally, it would be good to be clearer on the intent - recent discussions have suggested that the main data/publishing gains are found by working with a small number of big publishers/donors - who do not use these type of systems - this system would support more tiny publishers (who mainly publish a few static/non-updated projects because a donor forces them to) - but given that most analysis e.g. the work done by DI on realtime-analysis, the Country data tool, most research papers etc - all these tools immediately drop/exclude all small NGO data (it is mainly double/triple counting), then this big investment will have little beneficial impact for many of the major use cases? Again, the cost/benefit of this investment may be far worse than indicated.

S. Vaessen

I fully agree with Matt's comments.

I hope it is not the objective for IATI to monopolise this specific space, but its actions seem to show that it does - at least anything related to software services.

As we spent a somewhat painful process to get Datastore V2 out, Zimmerman as one of the providers of data tools in the IATI space has never been able to pick up on some of the remaining issues that needed to be addressed as per technical review, which I am happy to share to anyone interested. There was 0 cost benefit analysis performed by the IATI Secretariat seemingly had no interest in continuing to have us fix the output from the technical review.

I believe something similar happened to Data4Development upon delivering the Validator and I expect a similar incident to will occur if some technical party now wins this RfP, builds the basic, then gets the sack and the IATI Secretariat is called into the rescue as if the actual technical provider was not able to fix it themselves at a lower cost onboarding another developer on the IATI Secretariat. This way conscious communication disruption and an inability by the IATI Secretariat to work with technical parties seems like a strategy itself:

(1) public RfP,
(2) work with a technical party,
(3) do not offer technical party the option to fix issues
(4) IATI Technical Team takes over.

Not only is this not a very effective way of cooperation nor is this very transparent. How much would the costs have been if the Technical party had fixed the issues vs how much is the IATI Secretariat spending on in-housing the software?

Perhaps a lesson is learnt, but I’d be hard pressed to see any changes on how this RfP is handled. I’d expect some technical parties to respond, one of them building it and in the end IATI building out the rest? Next to Aidstream, the AIDA Platform will also be offering a very identical tool as part of AIDA in Q1-2021, which will allow organisations to publish IATI compliant data that will be synced to the IATI Registry etc. etc.

I am still mesmerised as to why no actual efforts have ever has been undertaken by the IATI Secretariat to unify a set of organisations that have been supplying all sorts of IATI data tools over the last decade.

From where we stand it looks we will have 3 versions of "Aidstream" early Q2022:

(1) Aidstream
(2) AIDAStream (working title)
(3) IATI PD (Publishing Tool?)

Why, one wonders...

No benefits, just a complete waste of managing resources imo.

Melinda Cuzner

Thank you for your reflections, Matt. But Aidstream, D4D and CoVE can bid and thus get economic support to further develop their tool (according to a specification brought forward from an in-depth consultation and analysis) and make it available to a wider user group. It would not follow good practice to give the money directly to any of the existing products without going through a proper procurement procedure.

I think you will find that the secretariat has greatly improved their procurement processes with NFRs etc. I trust it will lead to a well integrated solution.

S. Vaessen

The procurement process would have been greatly improved if framework agreements were made with some of the IATI technical suppliers in the IATI space that develop, service and manage these tools in a much wider space that just IATI. That way it would have been much easier to prototype and learn rather than to be actually stuck in very strict RfP environment. I honestly fail to see how this will be any different.

Gyan Mahadew

Respectfully, trust is maybe the main concern for professional participants in this space. If the true goal is to increase transparency, we should engage in an open dialogue and (at least try to) align common interests regarding advancing the IATI standard. As Siem, and Matt, our door is always open to continue the conversation.


[~567] - in case not seen - please can you share the underlying report mentioned - without this it is extremely difficult for the community to engage as we may not be aware of all the facts

S. Vaessen

[~2] a kind reminder to share that underlying report as the community now is unable to grasp the full story here and is unable to participate in full.

Melinda Cuzner

@mat I'm sorry that I didn't respond. It is specified in the RFP that the report will be shared with the winning bidder, so it wouldn't be appropriate in this stage of the procurement process to share it more widely.

On a more general note the UX reports haven't been shared previously either. Can you explain in more detail the purpose for community engagement in these? Don't get me wrong, community engagement is always appreciated, but with the reports there's no further feedback required.


Hi [~567] - thanks for confirming - the point I am making is that community engagement is probably not something IATI can just use when it wants to, and ignore otherwise - that does not feel much like a community to me. RE the UX reports - until the community can see them, how can we know if we have something to offer? RE the report - please can you say why it is being kept just for the board and the winning bidder, or is that a secret also? Who decides which documents about IATI are secrets, are there rules somewhere?

Melinda Cuzner

Hi @matmaxgeds.
"community engagement is probably not something IATI can just use when it wants to, and ignore otherwise"
- The community can always express opinions and preferences and suggestions but the secretariat can’t always act on all of these. Furthermore, it may be necessary to limit the scope when doing research for a report, and sometimes what is needed is the perception of community members that don’t regularly engage on these forums. Of course the secretariat need to be mindful of the balance between the need for community input and not burdening the community more than necessary, thus not always calling on the community.

"RE the UX reports - until the community can see them, how can we know if we have something to offer?"
- Do you mean in regards to possible tenders from the community? The RFP includes the relevant outcomes from the report so it should be sufficient for this purpose.

"RE the report - please can you say why it is being kept just for the board and the winning bidder, or is that a secret also? Who decides which documents about IATI are secrets, are there rules somewhere?"
- The report points to both strengths and weaknesses of products from various suppliers. It is not in IATI’s interest to widely share these findings for obvious reasons.

Steven Flower

Having worked with hundreds of organisations through the original CSV2IATI, then the hugely-impressive AidStream, and more recently our very own CoVE service - I wish the IATI board and secretariat the best of luck with this venture.

My experience of these past ten years tells me that no one solution fits all. Indeed, it's often the case that a specific tool will always be the worse-case option: production of IATI data is best served when it is integrated into the systems organisations have already invested in. This minimises the risk that IATI is externalised and therefore dropped or forgotten (especially if there is no use or feedback on the published data).

I'm therefore hugely surprised that the board and secretariat see it as a priority that a brand new "publishing tool" will address data quality. The "tool" is not the answer here. It's the boring backend of business processes, data workflows, project management and common identifiers that offer the solution. Has there been any consideration of such integration principles?

It's always been my experience that when engaging with technical teams in organisations, IATI gains huge credibility through the provision of schemas, codelists and rulesets. IATI suddenly becomes viable. It's very rare do organisations ask if there is a tool.

Yes, some organisations may use the services that are available, especially if they wish to prototype, or IATI has not yet reached their work or resource plan - but serious players integrate rather than separate.

Some of the very best IATI publishers are those that have integrated the schema in to their data systems and QA processes. For them, IATI is just one of many outputs. There's no "IATI input", as that is conducted through their existing systems. I fail to see any appreciation of this via this strategy.

For the IATI board/secretariat to actively include "free-to-use" in a software tender is, frankly, illogical. As Matt points out - twinning software development with service delivery is peculiar, at best.

Lastly, it saddens me a great deal that the board and secretariat have chosen to produce materials about the market-provision of existing tools and services - most probably by existing Members of the initiative - and then refuse to share them. A community spirit of IATI seems to have been lost, or mislaid. I hope however this venture is conducted, we can try to get some of that back.

Michelle Levesque

[~433] - I could not agree with you more on the fact that the hard work of publishing has nothing to do with the tool used to convert our data to XML but ALL the upstream processes to get us to the data that is needed. In my humble opinion the "tools" publishers need is usable code lists and clarity on what the data users need and guidance from experienced publishers. If a publisher is asking for a technical tool to help them publish with the understanding that it will make things easy or easier then they are probably missing the big picture on what it takes to publish.

If anyone has looked at our data they know we don't have financial transactions in our data yet. We've been working on this for over 1.5 years and the issue isn't with the tool we use to convert which is CoVE. It is taking our in-house programmers time to write the programming to get the data out of our ERP and me and my team mate, Jhuford, time to review it and provide feedback. This is an iterative process and in the meantime I continue to ask a bazzillion questions on what the standard means by "incoming funding" (see post in data use community) or how to address multiple currencies, or what should we do when we have a project that ends on the first day of the year and the schema doesn't like the fact that the annualbudget end date is the same as the annual start date (don't try and untangle that; just trust me that it is an issue) or how do we know what donor reference to use on an activity if this isn't explicitly stated in the donor agreements because no one has the manpower to run around after the fact and chase down these pieces of information.

I can't speak to the history of tools nor what what information is or isn't being shared in this space but the real tool for publishers is knowlege and guidance from data users and other more experienced publishers and understanding from all that compromises will have to be made from all involved.

Steven Flower

That's an excellent point [~325]

When I read that this new tool should be " simple, intuitive and aligned with the IATI schema and rulesets", I feel that all tooling I've used has aligned with these characteristics. CSV2IATI was (probably) the best of them :)

But - as you highlight - there are many parts of the standard that are just not " simple, intuitive and aligned with the IATI schema and rulesets". With the recent COVID-19 IATI project at the Centre for Humanitarian Data we noted the widespread omission of commitment type transactions, or that organisation references were absent to a huge degree, for example. This poor quality data does not arise from data publishing tools, but from a lack of community norms in publishing.

So - I certainly agree that tooling and services to further clarify and solidify the expectations and characteristics we expect from published data would be immensely helpful. Following the lead of the standard in the provision of schema, codelists and rulesets, I'm sure people could be tasked to build suitable stuff to help both policy and technical teams, in their ongoing implementation and integration of the standard.

To my mind, none of that really rest in a standalone "data publishing tool".

Melinda Cuzner

Hi Steven and Michelle,

I´t is great to see that the MA left you both with the zest to discuss the publishing tool. I'm afraid I am slower to react and have been pondering your comments during the whole Christmas break.

I’m afraid there are some misunderstandings in regards to what is intended with this publishing tool. It is in no way thought to replace healthy publishing routines, it is not thought to solve all publishing problems or needs and will neither solve the complexities of interpreting the standard nor is it thought to replace guidance and support in these areas. It is thought as a possibility for publishers that wish to publish (or are required to publish) but don’t have the possibility to integrate the IATI file generator into their internal systems.

In the initial research, publishers of different sizes were asked about their current publishing routines, their publishing experiences and if they would be interested in an external publishing tool. This was to check if there at all was an interest in an external tool and if so to ensure the new tool targets the right audience. As expected, most large publishers have already integrated their IATI file generator with their internal systems and prefer it that way. But the secretariat did not want to simply assume this and thought it was better to ask.

However, as you have worked with publishing support, Steven, I am sure that you have run across organizations that don’t have the time, the money, the know-how or the interest to create integrated reporting systems. I sure have, and there has been an interest shown from the community. If nothing else, to allow new publishers to prototype (as you mention yourself) their data according to the standard, which allows them to get further acquainted with the IATI standard and see how their internal input matches the IATI standard’s output. We both know this is quite the learning curve. The tools available are great, they all have various strengths, but IATI has no right to expect adjustments to be made to them to meet requests from the community or meet other needs expressed to the secretariat. Some of these adjustments do impact data quality, including UX improvements; it should be easy to do it right. The schema and ruleset is, as you both mention, complex enough.

You come with some great questions and suggestions, Michelle, that can lead to activities from both the secretariat and the community. It is very encouraging when members of the community discuss the code list, which helps clarify uncertainties and leads to wider communication. We should ensure feedback loops are installed and used, and we should share best practises for publishing routines. This is useful not only for the publisher, but also for the data user.

Finally, I must ask. Does the community really think it is appropriate for IATI to share reports that illustrate the strengths and weaknesses of tools from external providers, especially if it is for products that IATI has not procured? Objective but candid analysis of existing tools can be very useful for benchmarking purposes and internal analysis. But is there not a risk that it seems IATI intends to smear or boost particular vendors/tools if they make these reports public?

Thea Schepers

Hi all,
I agree that we shouldn't forget the small publishers who often don't even have a project management tool at all, let alone a way to integrate it with IATI. Those publishers are crucial in traceability of financial flows and results from the initial donor to the actual projects on the ground. Without them, we are a donor transparency tool, and I hope we have higher ambitions. But we're not always making things very easy for the small ones.
So I do think a standalone tool is necessary. It will not fix many data quality issues, but we do need it. Big publishers will not use it but the target audience is a different one. That audience does not weigh in on discussions here because they hardly understand we exist as a community, but they struggle with publishing and a good tool - built with input from the community! - is one of the basics we should provide.

Steven Flower

Thanks [~567] & [~584]

Can I ask: has the outcome of the tendering process been decided yet?

In terms of :

> Does the community really think it is appropriate for IATI to share reports that illustrate the strengths and weaknesses of tools from external providers, especially if it is for products that IATI has not procured?

Yes, absolutely! I fail to understand why such a report should be kept secret. Surely, if the research and methodology are fair and robust, then there's a) no need to be concerned about slander b) actionable feedback available to those maintaining other tools and c) a public channel open for discourse. Otherwise, having reports such as this locked away and inaccessible will ultimately undermine the public good we all seek to create.

(I'd also argue d) the production of such a report was funded by Members)

Thea Schepers

I would tend to agree with that. If the report is worded in such a way that sharing it will be a problem, that probably will lead to issues in the long run anyway because once it's shared with the winner of the bid, it will be 'out there' and will eventually end up in the hands of people who will be unhappy.

Thea Schepers

Also one more comment on the necessity of the tool: Aidstreams current maximum of 20 activities will no doubt lead to organisations unpublishing closed activities, which is a big problem, in my opinion. Historic data will disappear quietly, limiting the insights we need.

Steven Flower

These are interesting points, I agree.

But: I'd prefer to understand if these were points made in the research paper that went to the Board, to make the decision on commissioning a brand new tool.

Please log in or sign up to comment.