[OpenSpending] Follow-up to transaction standard call

Mon Oct 22 13:58:33 UTC 2012

Some answers in line.

On Sat, 20 Oct 2012, James McKinney wrote:

> Good points, Alistair. A few replies in line:
>
> On 2012-10-20, at 11:05 AM, Alistair Turnbull wrote:
>
>> I remember that a big obstacle to getting things from the data was that 
>> various government organisations paid each other to do things, so that 
>> the same money showed up multiple times. This was particularly true 
>> within the NHS. It makes it very difficult to get accurate totals.
>
> How does transaction-level data get around that? Either way, don't you 
> see a disbursement from one account and revenue in another? Or was COINS 
> not publishing revenue, only expenditures?

I think that was a problem, yes. The main problem was identifying when the 
recipient was another one of the statutory reporting bodies, meaning that 
the same spending would show up in both reports. Given that info, we could 
have inferred the revenues to the necessary extent. Allowing for "private" 
income too would have been a bonus.

>> To avoid this problem, I think we would need:
>>
>> - Transaction-level data.
>>
>> - Useful data about the recipients of payments, by which I mean that it 
>> should be possible to see if the recipient is another government 
>> organisation, and if so which one.
>
> At the transaction level, money moves between accounts, not between 
> organizations. Money can move between accounts owned by the same 
> organization. "Recipient" is therefore at least one level up from 
> accounts (putting aside the question of "beneficial owner"). What data 
> is currently given in COINS?

Indeed, but if you have the movements between accounts you can draw the 
boundaries wherever is most appropriate, taking account of the commitment 
system described in your previous email, and then get the totals you want.

I'm a bit out of date with respect to the COINS story, sorry. I'm not 
confident I can usefully answer your question. Anybody?

>> I worry that contract-level data would miss a lot of interesting 
>> information. Payroll, for example. Also cost overruns, non-performance, 
>> disputes, and mismanagement would show up in transaction-level data but 
>> not in contract-level data. Many procurement decisions look sensible on 
>> paper...
>
> Interesting to bring up payroll, because in many countries that 
> information is protected by privacy laws. In general, transaction-level 
> data raises important privacy concerns, eg employee expenses.

True. It would at least be nice to see totals, however, as payroll is a 
significant form of spending. It won't show up in contract data.

> Cost overruns are easy to see even at a high-level. Governments 
> regularly spend more than they budget. There's certainly interest in 
> determining where those cost overruns are at a lower-level, but I don't 
> see the need to go to the lowest level. Same for non-performance.

I am assuming that the lowest level is easier to obtain than a more 
processed form. Maybe that's not true?

The processing step involves a certain amount of creative input. I think I 
would be more comfortable if that creativity came from the public rather 
than from the government.

Anyway, if I have understood correctly you seem to be accepting the 
broader point about contracts not reflecting the true spending.

> Certain forms of mismanagement can likely only be seen at the 
> transaction level.
>
> How do you see disputes given only transactions?

I haven't really thought it through to be honest. I think probably both 
contract data and spending data are needed, so as to look for 
discrepancies. I was really only observing that you need at least some 
data from after the goods or services are provided.

>> I can see that contract-level data would also add lots of new useful 
>> information about the purpose of the transactions. I don't think either 
>> of transaction-level data and contract-level data really replaces the 
>> other.
>>
>> Bulk of data is not in itself an insurmountable problem. We have 
>> computers and dedicated people. Given ledger-level transaction data the 
>> task of reducing it is manageable, provided the books balance. However, 
>> if you get a dumbed-down version of the data that has been processed 
>> and reduced and summarised so that it no longer balances, then you 
>> don't really have anything at all.
>
> Insurmountability is a very low bar :) I would not underestimate the 
> time it takes to properly model an accounting system, so that it's 
> possible to ask of it the sorts of questions that are interesting.
>
> Anyway, I'm not against transparency at the transaction level. I'm just 
> curious to figure out if the common use cases and requirements can be 
> satisfied without going that far, because I think going for the 
> transaction level will be a lot harder, both in terms of getting the 
> data and in terms of using it.

Well then, maybe it's a question of finding the appropriate ambition! 
Quick fix or long-term solution? Easy for me to say when I am not the one 
doing the work, I suppose.

 	Alistair