Auditing of Sensible Taler

Reliable payments can only exist when the parties involved can be subjected to auditing scrutiny.

The explanation of full backing in underlying value showed the abusive practices by goldsmiths, which was could have been stopped with proper auditing of their business practices. Fiat currencies can be audited, but have legalised partial reserve systems by allowing commercial banks and central banks to create currency at will. (Fiat currency is a pun on fiat lux, "there be light".)

Digital systems, and especially when they form peer-to-peer networks, could easily go awry by not fully backing the value of the currency that they release. This is compansated by a trust network founded in legal contracts, digital signatures on financial statements, tailing such audits by their peers, and the revocation of trust in case of abuse.

Opening up for audits is what stops parties from abusing their ability to create money, and the definitions of Sensible Taler clarify what counts as abusive practices.

Some of the audit data is considered private, though. But the need to see this data depends on the auditing needs, which are not the same for everyone. It is possible to reveal partial data, while locking in data not shown by way of hash, effectively forming a Merkle tree of auditing data, of which the relevant parts for an auditing purpose are released to parties.

Auditing Trails

Entropy. Auditing records may represent relatively small changes. Since they are securely hashed before being signed, they are easily offset with full entropy, by including random information of the same number of bits as used in the secure hash.

Consistent time-line. Auditing records are digitally signed, time-stamped series that are made publicly available, even to anonymous parties. The trail is built by making a reference from each record to the preceding one. Anyone recording digitally signed branching in the auditing trail holds evidence of forged audits. The same holds if anyone records a digitally signed auditing statement that falls between two other digitally signed auditing statements by the same party. Once audited, data cannot be retracted. At best it can be corrected with a subsequent audited statement. Timestamps are based on internal time keeping, and may deviate slightly from timestamps by other parties, but not heavily, and changes of order should at most occur due to concurrent trades.

Correcting mistakes. Audit trails may hold mistakes. These can be remedied, but not by taking them out of the trail. Such corrections would point at the part of the past that was wrong, but continue the time sequence. The records straightened will be explicitly removed and/or added, noting the reason for each change. If this happens regularly, then peers may consider pulling back their trust in a payment system, most likely after taking out their posessions. Since the system ought to be fully backed, this is an undeniable right.

Trust itself is not a statement of faith, but lost faith can nonetheless be a reason to (temporarily) stop trading, or to untie a trust relationship; in the end, peers are under no obligation to install a trust relation if they do not want to. This is all part of imposed pressure on payment systems to provide spotless service. The days of fraudulant goldsmiths must not return.

Full backing. Every audit record involves a balance. Never must there be a point in time in an audit trail where the balance is negative; the Sensible Taler currency in curculation plus the cumulative pay-outs must not exceed the cumulative deposits.

When an element of the audit trail is not fully backed, then processing stops immediately, by all relying parties. Such an assault needs correction, and it will degrade reliance in the system, calling for active correction and a thorough explanation to be humanly judged before faith is restored.

When traded transactions do not appear in the audit quickly, then there is another problem that might hint at anything but full backing. The surrounding community collects information about the time it takes for a payment system to release transactions, separately for incoming and outgoing guarantees to each of the fully backed business parts. When transactions suddenly incur a delay, or when they gradually get longer, then there may be grounds to stop trading for a while. Technical reasons would work the same on ins and outs, but differences are a likely signal of problems with the full reserve; in that case, a fully reserved audit trail would process incoming before outgoing. This is non-existent when the logic of Sensible Taler currencies is properly implemented.

Committing to Anonymous detail. The changes to the audit record must be incorporated into it. This involves various lists of records, formatted as a list of timestamp, amount and secure hashes of the individual records, occuring in time order, each prefixed with a random seed that should normally be the same size as the output size of the hash. These records may not be available to all parties, in the interest of anonymous processing, but nonetheless the signature counts as commitment as part of the audit trail. The lists themselves, are visibly part of the audit record, so at least the number of records is clear. TODO: Random seeds, when published, may be reversed by trying probably transactions. This is not desirable. Build the randomness into the hashed data itself, but keep it synchronised between peers. The PGP signatures on records already hold enough confusing entropy to organise this properly.

Detaching in and out. TODO: Could we list incoming and outgoing value separately, by listem these parts separately without coupling them by way of transaction identities? At the very least, this would be reasonable in auditors who are not looking for money laundering but merely the fully backed operation of the business. This may mean that the coupling information is a separate list to record. Or the party doing the transfer could be decoupled, and the connection between in and out made by way of same transaction identifiers.

Anonymous Auditing

All customers want the assurance that their payment system does not break the fully-backed property. This is also a demand for those who consider becoming a customer. The top-level audit trail must therefore be available to them without indication of who they are, also to ake away the lure and possibility from the payment system to release individualised audit trails to each customer (which would also break the consistent time-line, but make it more difficult to detect.)

Anonymous information should be liberally distributed. Since it would be digitally signed and the data is public anyway, there is not even a strict requirement to secure the transport. So, email to a list of subscribers or simple downloads would be fine methods of delibery.

Customer Auditing

When a customer identifies themselves and, if so desired, authenticates, then the relevant auditing records holding their information can also be released to them. Anything not mentioned is then considered to involve (still anonymous) other parties. Customers with multiple identities may be served with multiple such records in one go (which would be useful for a group or company with multiple trading identities) or they may collect the data independently from various queries and should not find any conflicts. In fact, this kind of merging of information enables outsider validation of the records that are normally anonymous, inasfar as these parties agree.

Merging of data from identities may also be used to test the system to perform its audits as expected during (covert) inspections that verify if all data is being audited properly. There is no ban on any such inspections by any party, as long as it does not interfere with normal business operations. Tests may also incorporate data from across the trading network, under the same fairness assumption.

Since identities are core to retrieval of information related to title of ownership, authentication generally should be controlled independently by the customer, effectively meaning that it should be possible to fallback on a user@domain.name identity under a domain chosen by the customer. Also, a modifiable set of alternative identities should be allowed on any such customer account, including the ability to migrate from an old to a new authentication identity without change of access rights to information and ownership of underlying value.

Trusting-Party Auditing

Trusting parties moved beyond anonymous customers of a Sensible Taler currency exchange. They have gotten in touch, evaluated a payment system's formal paperwork and come to the conclusion that there is a solid basis of trust that the exchange performs according to the Sensible Taler requirements. They usually negotiate a contract that legally binds the exchange. This trust relation may or may not be symmetrical; the rights stem from the desire to trust an exchange between a Sensible Taler currency and its underlying value.

At the very least, a trusting party must be able to find back their own transactions as previously negoated using FIX Trading. To this end, the trusting party computes a hash over the FIX exchange that led to the trade, and it looks for that hash in the list of transaction records. Normally, such records are (somewhat) private, but there may be multiple reasons for publishing them, auditing being the first. It is also worth noting that the hashes of the FIX exchanges are publicly visible, so they can be paired by sufficiently informed (and determined) parties. This can be combined with timestamps and amounts on the records to validate the correct pairing across traders, without knowing anything more about the trade than the elements that ascertain the full reserve properties.

The ability to check after one's own transactions establishes trust in one's own elements of trading, and since its hashes occur in the anonymous output it will be part of what everyone else sees in terms of claimables, but there is a vital thing still missing. How can a trusting party audit that the value is not obtained via unsincere channels, leading to unreliable or downright forged backing value? To address this, each party publishes the list of parties that it trusts. When this list does not completely cover the amount held in backing, then a trusting-party audit would render them untrustworthy and claim to have any value stored with them delivered promptly.

Parties independently have permission to publish their transaction information when they are (or were) on either end of a legally formalised trust relation. This means that a trade between two parties may be independently obtained from either side. The connectedness can already be matched publicly when both parties publish an audit trail, that is if they are available as trusted parties. Private users on the other hand, would stay cloaked but for their transaction times and amounts. Transaction records contain hashes over data involving many parameters, so these are not reversible.

TODO: Is it ever secret what trading occurs between parties that are open for being trusted? Or how much they hold on mutual accounts?

Bankruptcy Resilience Auditing

Valuables are on the balance of their current owner, regardless of where they are held.

This simple rule avoids that a bankruptcy could ever suck in the underlying value when a payment service is declared bankrupt. The funds are simply on an intermediate account that is independently owned. This concept is used by notaries, web shops and so on to give precisely this protection. These accounts are often used for escrow services, and controlled by caretakers who follow strict procedures in doing so. When a party goes bankrupt this can be organised by a disbanding executive service. TODO:TERMS.

The execution would be part of the company's legal setup, and must be in line with the regulations of its jurisdiction. Essentially, claims could be filed with the bankruptcy executing service to payout to any claimant who presents digital coins provided by the Exchange or who hold an account with the broke company. Note that all this only applies when the value is fully backed and kept off the balance sheet of the bankrupt company. These are points that will be checked meticulously during a trust evaluation.

This disbanding of service is likely to involve trusting parties, which then claim the contents of (notably) their mutual accuonts. Such action could also be automatically handled by the execution service by dispatching the value via another mechanism. This may involve balancing external parties as well, so they would be asked to book among themselves.

Finally, it is possible for parties to take over each other's backing value as long as they adopt the titles of ownership held to it. This means that they money once again stays off of their balance and can be claimed by the original owners. When this is done, it must be done in a manner that works for one-time claims without formally creating an account or other relationship. It may of course be offered, giving the end user the choice to continue their business with the new party. It is possible that an bankruptcy executor grants individual users of the bankrupt payment system the choice where they would like to continue with either a one-time cash-out of value, or migrate their ownership.

The value of authentication based on a domain chosen by the client was already mentioned before. In this case, it presents a very clear advantage, because only the identities must be passed, not any corresponding credentials.

Tax-Related Auditing

For purposes of tax auditing, the essential information are a single party's income and expenses. Where expenses are made, it is important what other party was paid. And it is useful to mention a unique number for book-keeping records such as bills.

It is not normal for tax offices to demand trading details for all parties. It is however important that they see from the audit trail that the transaction set (in the given payment system) is complete, and that no transactions for the investigated party are left out.

Tax records are usually supplied by the party being audited. They can present a system-signed statement that clarifies the completeness, and that digitally signs for it. The useful thing here is that signatures made by a third party are highly unlikely to be false. In general, it is even sufficient for a tax audit to assume that a party is not lying to protect its interests, because they would really be in trouble if it were ever discovered.

In addition to this data, tax offices may want to see the value kept in accounts (or the value held) on behalf of all parties in their jurisdiction. There may be a requirement to list such data for all parties in the tax office's jurisdiction at fixed times, such as the change of year.

This form of auditing may be unnecessary for tax purposes when the underlying value is essentially zero in the eyes of the tax office, or difficult to tax. This may well be the case for Sensible Energy (the ability to trade eneregy at a null tarrif). It is generally important to balance privacy laws against the legal pressure imposed by people such as tax officials.

Financial Watchdog Auditing

Financial trading bears a risk of abuse, which is not softened by a change of the monetary units. For this reason, legal enforcement of a few related mechanisms are common:

• Know Your Customer is the principle of verifying identities
• Anti-Money Laundering is the tracing of large transactions

Both are supported in GNU Taler to allow any kind of money to be legally valid. Whether you need to implement them depends on your business and its jurisdictions.

The audit trail shown to financial watchdogs must include large transaction records, including the identities of the traders involved. This selection of records may be separately stored for that purpose, so it can be shared in one complete package. Or it would be possible to flag them on the spot.

Note that a series of transaction records might pile up to a large enough value to trigger the amounts that would trigger financial auditing requirements, had they been individual transfers. This may be avoided at any time by splitting the audit trail before it reaches those trigger amounts. This will then automatically be done for individual transactions that are high enough. One such transaction can then be stored as a single auditing period (and record set), so as to share that full package to the financial watchdog auditors. They can discover easily that the other auditing records are too low to be of interest to them, and they might even be off-limits for reasons of privacy, because evidence exists that these transaction(set)s are too low.

To facilitate this trigger-avoidance, it is helpful when claims on an Exchange are also not made to cross the line, unless it is for a single transaction. So, when claims are batched, then it is helpful to keep the batches small enough to try and stay below the watchdogs' thresholds.

Note that the thresholds may also determine the selection of records that are to be shown. In other words, there is no strict requirement to store them in a special form, not unless the information kept might otherwise be incomplete.