Corda in Audit/Accounting Businesses


(Max Timmerbeil) #1

hi there,

I am writing to hopefully kick off a conversation on possible usage of Corda in the Audit industry. I have yet to decide which software we are going to use for our technolization processes but after a few days of reserach, we put Corda in our list of top three candidates. So who has any examples of audit or accounting based Corda applications? Who has heard of any firms or institutions using Corda for accounting, bookkeeping etc.? What should be the first steps to install Corda in such a business? How would a typical Corda administrating team look like?

In case you have any suggestions or answers, please go ahead. Also in case you have any valuable contacts that could help me answer these questions in greater detail, I would highly appreciate the link up.

Thanks


(Roger Willis) #2

Hi Max, I used to audit banks at EY and am now a member of the Corda platform team. I’ve given DLT/accounting a fair amount of thought over the past few years and believe you are right that Corda is the best tool for the job!

There are a few things to make clear though. DLT is used for the immutable recording of transactions between potentially distrusting entities, however DLT should NOT be used to actually facilitate the accounting ledger. Accounting records are private and should not be shared with any outside parties… Why?

Two entities in different countries can treat the same transaction quite differently on an accounting basis. One entity may have a special dispensation to treat a transaction differently on an accounting basis, etc. Why should that record (which is relevant to a specific entity) be stored on a shared ledger?

This is what Consensys didn’t understand (and probably still don’t by the looks of it) when they worked on blanc3 (unless it was for use by charities or other entities that were not bothered by the absence of confidentiality).

Instead, what we need to build is an interop layer between the DLT and existing accounting systems. Think of this interop layer as a function that takes:

  • ledger data on Corda
  • some accounting rules (e.g. IFRS IAS 32 - fair valuation of financial instruments)
  • some reference data regarding balance sheet and P&L accounts
  • a mapping of legal to management accounts

and produces standards compliant journals and posts them to the correct GL accounts.

Anyone using a block chain or DLT to actually store accounting entries is doing it wrong, instead you need to build an interop layer between the DLT and the GL.

Ping me a message on the Corda slack if you’d like to talk further on this.

You might find my old blog useful: https://medium.com/@3ntry

Cheers


(Sander van Loosbroek) #3

Hi Roger, we are currently working on a reporting layer on top of Corda and I ran into the same train of thought. To build an immutable audit trail Corda can be used in many different ways. In some of our previous proof-of-concepts we stored accounting data as part of the loans that were under our control, while this works well in practise (you can prove that the accounting of the loan was not tampered with) it does not scale with the road map of Corda in mind. We need to associate accounting information with the transactions that occurred on the ledger but the information (i.e. a state property) can’t be a part of the actual loan.

Curious to learn what your thoughts on the matter are to date.

KR,
Sander


(Jiri Jetmar) #4

Hi guys,

this is indeed a very interesting topic and from my perspective relevant to any serious business activities using a
DLT in the financial industry.

We started to use the DLT first as an integration approach between our external partners.
I know that “classical” approach are more API-like, where the “API” can be everything between a
plain CSV file on a (sFTP) server or a full-fledged FIX gateway. The term “API” is nowadays pretty buzzing,
from my perspective lots of issues like security, confidentiality, integrity, maintainability are not really solved well
. I could argue here in many different directions, but this is not the topic here.

However, we realized also that we can not convince our workflow partners to use a DLT, at least not short-term.
At the other side, it had turned out that the DLT can be i) messaging ii) workflow and iii) a database solution with some
unique features like the delivery data to (internal) parties that are legitimate to see them,
transactions are validated and processed only by valid parties to the transaction and much more. E.g. try to implement
"bi-temporal" journaling on top of classical databases. The DLT offers it inherently.

This are features that are very interesting for accounting as well. These properties can also be achieved with classical strategies (ETL jobs, reconciliations) but require a lot more effort.

I also agree with Roger, that it does not make sense to implement any kind of economic, regulatory, … risk accounting/ reporting directly
on the DLT, but instead to consider the vault (in case of Corda) as a unique (golden source) of truth. The accounting domain
can participate in a number of CorDapps to receive data about involved partners, their contract, product-related data, eg. status/valuations
of the collaterals, payment transactions, etc… Such an audit trail is a source for any other concrete accounting reporting
activities where usually lots of “numeric massage” like IFRS impairments, valuations, risk provision and much more is done.

So far so good … a question now - how to test the whole thing - end-to-end? This is usually a pretty hard thing to solve when you have a
number of systems/domains that own their own “truth”. How to avoid deltas? From my perspective close to impossible… and a
very nice feature of DLT - you have only one truth!

Therefore testing is pretty simple - lets export the vault to a plain ascii file, import it to hledger.org or ledger-cli.org and
you have a full double-entry accounting system. You need more? Export transactions/balances on dedicated sub-ledgers, do whatever "massage"
you need using a special/magic IFRS/HGB/GAAP tool… export the sub-ledgers… and import them again to hledger/ledger… done.

Best Regards,
J. Jetmar