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.