A follow on from “block chains and the future of audit”

This post is in response to a great article by Matthew Spoke on Coindesk, which discusses financial audit and how the block chain may help to improve it.

Have a read and get up to speed. All done? Good.

One thing that article didn’t discuss was any specific architecture or implementation details. That’s what I’ll explore here, with the aim of answering the question, “is the future of financial audit all about block chains?”.

We’ll have to cover a fair bit of ground but firstly…

Focusing on audit misses part of the problem

Auditing is hard. It’s also terrible value for money as only ‘reasonable’ assurance is provided and this assurance is often misplaced. Everyone loses as a consequence when fraud and errors go unnoticed.

The expense and fallibility of audit are symptoms of two broad ranging problems, only one of which gets any air time

“Financial audit and the audit firms need reforming”

The solutions range from mandatory auditor rotation to big data. Will they have any impact?

Perhaps. Auditors have their own problems, however I’d argue that one of the key issues actually lies with our approach to building accounting infrastructure, transaction systems and developing accounting workflows.

I’ve touched on this before, so I won’t go in to detail here. Summary:

ERP software is abysmal, no digital signatures, bad data interoperability, poor usability, poorly built spreadsheets, reliance on manual tasks, data duplication, etc…

A common busy season occurence

Audit is an afterthought to all but the auditors themselves. To quote Paul Graham, it’s a “schlep task” — tedious unpleasant work. As each accounting journal is posted the ‘audit debt’ silently accumulates, like dirty plates that gradually build up next to the kitchen sink.

Audit partners are ambivalent providing they can charge over-runs for their staff to locate paper bond indentures in the basement and review a multitude of spreadsheet cluster-fucks. Don’t hate the partner.

Mission critical spreadsheet workflow

Believe me when I say there are a lot of hidden costs here. It doesn’t have to be like this though — it turns out that the thinking and technology to edge us closer to audit utopia has actually existed for over a decade.

Clue; it’s not

At the “audit innovation” meeting…

as some would have you believe.

Instead, we should focus on auditing as much as we can when it happens, rather than doing a “reasonable” job making sense of the mess afterwards.

Back to the block chain

In creating Bitcoin, Satoshi’s key innovation was the permissionless block chain, a shared replicated ledger (“SRL”) with a focus on censorship resistance. It’s a pretty amazing piece of technology, but hold your horses — we aren’t going to jump on the block chain band-waggon just yet.

Censorship resistance driven by proof-of-work is key when one is operating in a highly adversarial environment, like a cash system, where the identities of your counter-parties and transaction verifiers are not necessarily known. The Bitcoin block chain was designed for this exact use-case — where exploits and government crack-downs are the most concerning threats. A currency system needs to be secure and Bitcoin achieves that.

And what are the disadvantages? Bitcoin is slow, proof-of-work (although currently subsidised by mining rewards) is expensive, transactions must be publicly broadcast and governance is sub-optimal.

Similar trade-offs are inherent in the design of any SRL. Take Eris for instance; to allow for more effective governance, oversight and control of their block chain design, they have had to sacrifice decentralisation and censorship resistance.

This is the key — each SRL must be carefully designed to match domain requirements and block chains won’t always match our requirements optimally.

SRL as a concept, block chain as an implementation

We should cease thinking in terms of block chains and instead view them as just one very particular implementation of a SRL. Indeed, there are many ways to implement an SRL; Hyperledger, Eris, Ripple, Open Transactions, etc.

Firstly, what is a SRL? Richard Brown defines “shared” and “replicated” as

Shared: because multiple actors can read or write to different parts of the ledger

Replicated: because everybody who needs a copy can have a copy, rather than relying on a powerful central entity

and for completeness, I’ll bolt on

Ledger: An immutable append-only collection of records

In my view, SRLs mostly solve accounting and transacting problems so our efforts should focus on

“What things do we need to transact and account for, what’s the problem with the current method and what do we want to achieve?”

As opposed to

“What can we apply block chain technology to?”

Companies of all shapes and sizes around the world are currently at panic stations, asking the latter question.

Perhaps we can use a block chain, Factom will do, to expensively, securely and pseudo-anonymously — because it’s embarrassing — record all the superfluous block chain uses we came up with, so we can look back in 100 years time to laugh about the band-waggon of investor money that was wasted.

Workflows and infrastructure

The main problem which SRLs can elegantly solve is this:

“Parties to the same transaction, record all source data and subsequent accounting journals unilaterally, in separate systems”

Bob and Alice are at it again!

In other words, performance of the transaction is separate to the recording of the transaction and its associated audit trail.

Some of the consequences are; wasted time, operational risk, fraud, increased audit costs, mistakes and more hidden costs.

Accounting frameworks, reporting currencies and fraud aside, both parties should be posting equal and opposite journals.

Each party should post a journal which is based upon the raw transaction data, e.g. bond indenture, swap agreement, invoice, certificate of deposit, repo agreement, building contract etc.

Therefore, for a valid transaction to happen, both parties must agree on a transfer of value at a point in time. Makes sense?

So, if all of this is communicated when the transaction happens, why can’t we build a robust, legally defensible audit trail for that transaction, for both parties, the moment it happens?

This audit trail gives us real-time assurance at the transaction level for potentially huge amounts of transactions.

So, how do we do it? What’s the lowest common denominator we require from a SRL to be useful from an general accounting (and audit) perspective?

Triple entry as a concept, SRL as an implementation

To make this work, we need a few (implementation agnostic) components:

• A secure channel to communicate transaction data between counter-parties.
• A way for counter-parties to robustly confirm agreement of a transaction.
• An entity or entities to notarise new transactions and store past transactions when required.

How would this work? Taking the classic Bob and Alice example above, here’s the work flow:

1. Alice issues the instrument, she signs it.
2. Bob receives the instrument, agrees with it and he signs it.
3. Bob passes the record to the Notary, who signs and then stores the instrument.
4. Bob, Alice (or an authorised third party) can now query the Notary to ascertain whether the transaction happened. Bob and Alice can also keep a copy of the notarised instrument themselves.
5. As the Notary is a SRL, it’s practically impossible to delete or update the instrument without counter-party approval.
6. Even if someone does, we’ve got an instrument with their signature on it.

Now, the part which is interesting for accountants and auditors. The instrument, triple signed by Alice, Bob and the Notary

“is the transaction as well as the raw accounting data for that transaction”

Therefore we can say that this workflow which Ian Grigg calls Triple Entry Accounting

“combines the act of performing the transaction with the recording of that transaction and its associated audit trail”

Ian’s paper has been on the web for over 10 years.

Now, instead of accounting for the instrument unilaterally in their respective accounting ledger’s. Alice and Bob can simply point to the triple signed instrument on the SRL, which contains all the metadata required to post the correct accounting journal and revisit the definitive transaction particulars.

Note the existence, occurence and valuation procedures — we get these for free with triple entry.

Alice and Bob now always have the same data — no need for reconciliations. Furthermore, accounting fraud is practically impossible using this system. Auditing is now easy-peasy as all SRL driven journals have a robust audit trail built in.

Lets look at Bitcoin in more detail.

Bitcoin in an audit context

It turns out Bitcoin already implements a triple entry system as standard. Perhaps Satoshi read Ian’s paper when he was developing bitcoind.

When we send bitcoin, the resultant transaction hash not only refers to the transaction but also the gives us the robust audit trail we need to post the associated accounting journal.

From an audit assertion perspective, we get

• transaction occurrence — did the transaction occur?
• balance existence — does the balance exist?
• balance rights & obligations — do we own the bitcoin?
• balance valuation — assuming the reporting currency is BTC
• balance and transaction cut-off — recorded in correct period?
• presentation & disclosure — we know bitcoin is cash.

for free — no need for bank confirmations and tedious reconciliations here!

Completeness is more difficult as Bitcoin is a pseudo-anonymous system. However we can use heuristic clustering on transaction inputs to figure out addresses which users may have not have disclosed to us. In any case, auditors can off-load responsibility to management through the rep letter.

Auditors will have to leave bitcoin completeness checks to the crypto-boffins. Image credit O’reilly

As no rights or obligations arise due to cash payments we don’t need to worry about what happens in the future. A payment either happens, or it doesn’t and thus in most cases, a public key, digital signature and a Pay2PubKey Hash script is all that is needed to ‘audit’ new bitcoin transactions at a basic level.

In the case of Bitcoin, the block chain is fit for purpose but of course, there are other ways to do cash. Ripple also implements a triple entry system — they just sacrifice censorship resistance for gains in other areas.

The above is indicative of other permissionless proof-of-work driven block chains.

Other instruments are more difficult to handle.

What about bonds?

A bond is a fixed-income credit instrument used by entities to raise funds.

Upon issuance of a bond, certain rights and obligations arise

The right of the bond holder to receive interest coupons and ultimately receive the principle in full.

The equal and opposite obligation of the bond issuer to pay interest coupons and repay the principle in full.

These rights and obligations could continue for up to 30 years in the case of a 30 year bond or in the case of a perpetuity, indefinitely. The obligations may run into billions of dollars.

For this to work in a SRL context we have to address

1. Identity. Who is the bond issuer?
2. Reputation. Will they pay?
3. Performance. How will they pay? What happens if they don’t?

Lets skim over identity and reputation for the moment. Assume we use PKI for identity and a credit ratings agency for reputation. We still need to consider performance and we have two options

1. A robust and fair legal framework that enforces penalties in the case of non-performance, i.e. English law. Payments are automated to a degree, however they still require sign-off by treasury.
2. Smart contracts. Smart contracts would be great but instead we only have dumb ones. These contracts manage the payments in an autonomous manner with decisions based on data feeds from 3rd party Oracles. The smart contracts platform would need to be robust enough to run the course of the contract. Likely?
3. A bit of both.

All this gets rather complicated, especially as we haven’t begun to consider issues such as managing credit risk, default, cross-default, monitoring, insolvency, debt subordination, securitisation, call provisions, etc. The solicitors and accountants have this covered — get your cheque books out!

Thoughts on the problem domain:

• We know the identity of counter-parties before we transact.
• Reputation, in the form of credit worthiness, matters.
• Longevity and robustness of the SRL is critical. There’s lots at stake.
• We need coherent governance, not a decentralised farce.
• Censorship resistance is not of great concern.
• There are a tonne of edges cases.

Putting my pragmatist hat on, it’s unlikely that block chains are the optimal SRL implementation here. Certainly not the permissionless proof-of-work driven type.

Permissioned block chains like Eris may have a place but it’s easier just to use something that isn’t as bamboozling, like a mysql database cluster and concentrate on things which matter, like good UX and coherent work flows.

Open transactions looks like a more appropriate approach.

Whatever implementation we go with, we should get the triple entry power and in terms of audit assertions, that means;

• occurence
• completeness (if we enforce the identity element)
• existence
• rights & obligations
• cut-off

come out of the box.

Valuation should be done as usual by looking for a market price or a decent proxy, otherwise do what most auditors do and use a heavily caveated report from the in-house expert. That’ll be £800/hour please.

Of course, I haven’t even scratched the surface here. Needless to say, it’s all bloody complicated and we’re going to need much more than our block chain hammer to figure it out.

Practical SRLs

If you are this far, thanks for sticking with me. Here are some concluding thoughts

1. Going forward, I believe we’ll have a SRL for each type of thing. One-size-fits-all SRLs wont work for a whole range of reasons, not least that they would be the mother of all (vendor) lock-ins. Ironic?
2. As each type of thing is quite different, these SRLs will be implemented in different ways. Some may use a block chain, others may use a classic federated (server) system, others may use something we haven’t designed yet.
3. Projects which use a block chain when one is not required will fail. Someone else will implement a better version using a mysql database whilst the block chain chaps are busy fixing a buggy distributed hash table, or something.
4. Ideally, accounting ledgers and other corporate systems of the future will ingest all this SRL data in order to post accounting journals and perform analytical functions. Note: we are not posting the actual accounting journal to a SRL, however we can use the SRL data to generate our journals.
5. Triple entry powered SRLs give you some audit assertions for free. So the lesson here is not to use block chains for audit but capitalise on the robustness of triple entry powered transaction data in SRLs.
6. Auditing things in the future will be a case of running scripts on the SRL’s data to grab the low hanging fruit. This is not “big data”, it’s just a database query that an auditor could write. Standard audit procedures apply for more subjective elements like valuation.
7. Smart contracts are not smart. They are dumb and will continue to be so. It’s more appropriate to view them as “business logic” executed in an expensive, decentralised virtual machine.
8. Smart contracts also don’t capture any of the intangible human elements of commerce and they probably will never do until we crack strong AI.
9. Some crypto-boffins have trouble building software for humans as we are today. Instead, they are focused on developing software for robots in 20 years time. For example the Ethereum marriage contract is great when your helper robots of the future want to tie the knot. Despite this, we thank them (and their investors) for their venerable efforts.
10. Intuitive work flows, good user experiences matter more than you might think. Barely anyone has cracked this yet and it’s of incredible importance as the majority of high paying corporate clients are infrastructure agnostic.
11. I suspect that most SRLs will be privately run (not by auditors as they should be independent!) to ensure flexibility and robust governance. No-one wants commerce to grind to a halt because some stubborn developers won’t approve a github pull request.

Closing remarks

The future of audit won’t necessarily be involve block chains. Instead, it will involve triple entry powered SRLs of all shapes and sizes which will be specifically designed to meet domain requirements.