Security and Financial Transaction Recording


One way to see money is as a security construct. Alice supplies a camel to Bob and expects Bob to do something in return. Alice loses out if he doesn't. If everyone's intentions and behaviour were pure then Alice could be equally happy if Bob did something as valuable for Ethel and Ethel did the same for Mallory and whatever goes round comes round to Alice at some point. In this perfect society money probably wouldn't be needed. Because people are not always honest the security of money as an accounting device and means of rewarding appropriate behaviour is needed.

Direct barter, e.g. getting a lump of valuable metal in return isn't always practical. So Mallory, who has a strongroom, acts as banker to Alice keeping the piece of gold Bob gave in return, and giving her a piece of paper to indicate the deposit in return for it. Mallory soon discovers that the gold stays in his strongroom to the extent that he can issue 7 notes for every measure of gold with little risk. One banknote goes to Alice and the other six are either lent out by Mallory at interest or perhaps he might invest them himself by building houses for rent. If Mallory's notes have serial numbers on them this makes it more possible to trace thieves who steal them from Alice or forgers who make copies of them.

Of course the abstraction from direct value to stamped pieces of metal and carefully printed pieces of paper didn't end there. Nowadays 97% of the money in circulation in the UK is in the form of chequable and electronically transferrable deposits and credit card limits. The world still contains our cast of characters intent on attacking the system for personal gain, such as Joe Semtex the bank robber, Ethel the bent securities trader and Dmitry Nyetovitch the money launderer etc. But with less cash moving around and more of the electronic equivalent, Joe's occasional audacious raids on bank vaults and security vans are netting fewer returns for greater risks while Dmitry and Ethel's criminal activities are expanding. The increasing complexity of the system has given our cast of misfits possibililites for a greater number of modes of attack.

The job of the financial systems security engineer in closing the increasing number of holes probably isn't getting any easier. Considering the rewards Mallory obtained from the construction of the strongroom in which Alice kept her gold, we shouldn't forget the price that everyone else has ended up paying those who succeed in the task of providing various kinds of security or persuading those who thought they didn't need this that they do.

George Bernard Shaw: "every profession is a conspiracy against the laity".

For a number of victims "provision of security" that they thought they didn't need is in fact a criminal protection racket.

More about the history of money

Various histories (e.g. Adam Smith, "The Wealth of Nations") suggest that money started out as lumps of valuable metal. The earliest metal coins date from around 650 BC. If recent archaelogical discoveries concerning ancient forms of accounting are correctly interpreted, earlier money may have taken the more abstract form of of clay warehouse receipts representing the goods concerned.

picture of Babylonian clay moneyPersian clay money

These pictures from the Complementary Currency Resource Centre suggest that accounted money predated metal coin money by at least 3000 - 3500 years.

It appears that a tamper evident mechanism was sometimes employed, by enclosing a clay tablet inside another on which was embossed a seal which would be difficult to forge.

Book cover clay tablets and clay envelope Denise Schmandt-Besserat in "How writing came about" states:

"The immediate precursor of cuneiform writing was a system of tokens. These small clay objects of many shapes--cones, spheres, disks, cylinders, etc.--served as counters in the prehistoric Near East and can be traced to the Neolithic period, starting about 8000 B.C. They evolved to meet the needs of the economy, at first keeping track of the products of farming, then expanding in the urban age to keep track of goods manufactured in workshops. The development of tokens was tied to the rise of social structures, emerging with rank leadership and coming to a climax with state formation.

Also, corresponding to the increase in bureaucracy, methods of storing tokens in archives were devised. One of these storage methods employed clay envelopes, simple hollow clay balls in which the tokens were placed and sealed. A drawback of the envelopes was that they hid the enclosed tokens. Accountants eventually resolved the problem by imprinting the shapes of the tokens on the surface of the envelopes prior to enclosing them. The number of units of goods was still expressed by a corresponding number of markings. An envelope containing seven ovoids, for example, bore seven oval markings."

Double Entry Bookkeeping

Early systems of accounting had to deal with the occasional corrupt insider. When business became too complex to trust record keeping to one person in one place, double-entry bookkeeping was invented. This still doesn't seem obvious, but the principle is that every transaction has to be recorded in one book or ledger as an asset and in another book as a liability. For example, a customer of a bank makes a cash deposit. From the bank's point of view, the contents of the cash till represents an asset, and the customer's deposit account is the bank's liability. It is obvious that the bank needs to keep score in terms of the deposit account. Double entry accounting extends to each bank branch - not just the business as a whole.

Why keep a seperate record on what goes in and out of the cash till as well ?

This means that the ledger recording money in and out of the till should correspond with the amount of cash in the till. Otherwise if the amount of money in the till is incorrect the discrepancy could not be traced.

But isn't a business supposed to make a profit and isn't this an asset ?

Yes but the profit a business makes belongs to its shareholders. If a bank has cash in the vault or owns deposits elsewhere which result from higher earnings than costs (i.e. profit) these will appear in the books as assets. Any profits that have been made are also immediately a liability that the business has to its owners the moment the profit is made, so if the book recording profits which the business owes to shareholders is kept up to date then all the books will still balance.

What happens if the business makes a loss ?

To start with, a business needs investment. This asset is capital the business can use to launch operations before it starts making a profit. In the liabilities book this is also the value of the business, which is what the business owes to its owners and creditors. So the 2 sets of books must still balance. If a business ends up costing more to run than it earns, the value of the business to its owners declines which reduces liabilities from the point of view of the business to its owners. Liabilities to creditors of a solvent business will not be reduced.

A business becomes insolvent when its liabilities exceed its assets and this insolvency results in creditors having to reduce their expectations of what the business can pay them back, so after these adjustments are made the books still balance. In the situation where the creditors receive a proportion of what they are owed, the business owners tend to get nothing.

Banking records and data processing

Accounting master file

This will contain each customers current balance, together with previous transactions over a certain period, and a carry forward amount representing what was in the account at the start of this period.


These track assets such as cash on their way through the system.


These track transaction inputs from check sorters, cash machines etc. not yet input into ledgers.

Audit trail

This records which member of staff did what and when.

Batch processing

This is typically a set of programs run in sequence at the end of a day's business, to input data from the various journals to update the relevant ledgers. An example might be a cash deposit by a customer into a savings account. The relevant journals should include deposits into savings accounts and cash put into the till. After all the inputs have been used to update the Ledgers, all the asset and liability ledgers should still balance. If they don't this indicates an error which results in an investigation.

The order in which batch programs are run can influence the outcome, e.g. by making payments into accounts occur before payments out of them, this reduces the risk of overdrafts.

Transaction processing

The reason for having seperate journals and ledgers is that this enables a batch to be rerun based on the same starting state if a failure occurs prior to a batch completion. Backup copies of all files have to be taken before a batch job is started, and these files determining the starting state of the system will be restored prior to a rerun. Software engineers describe the approach to data processing where a set of related updates either complete as a unit or are rewound to the starting state as transaction processing.

Preventing accidental discrepancies and maintaining the security of the system are intimately connected concerns.

Seperation of Duties

If double entry books are kept by different clerks, or computers, or sandboxed processes, containers or virtual machines under the control of different administrators, this leads to a situation where fraud requires the collusion of 2 or more members of staff, otherwise known as "shared control".

This principle is extended in banking to ensure that one member of staff doesn't have too much influence over the systems that keep track of what they do. Giving Nick Leeson management control over the Barings Bank Singapore dealing room and back office operations at the same time violated this principle. This events leading up to this and the consequent collapse of Barings Bank was described in the film "Rogue Trader".

The Clark-Wilson integrity model

This is based on an analysis of the procedures adopted by the banking industry based on the concepts described above, into a formal set of rules. The Bell-La Padua model relevant to Multi-Level Security is primarily concerned with information confidentiality. The Clark Wilson model is primarily concerned with information integrity.

Clark Wilson model terms

Clark Wilson rules states these as follows:

The model consists of two sets of rules: Certification Rules (C) and Enforcement Rules (E). The nine rules ensure the external and internal integrity of the data items. To paraphrase these:

C1 - When an IVP is executed, it must ensure the CDIs are valid.
C2 - For some associated set of CDIs, a TP must transform those CDIs from one valid state to another.

Since we must make sure that these TPs are certified to operate on a particular CDI, we must have E1 and E2.

E1 - System must maintain a list of certified relations and ensure only TPs certified to run on a CDI change that CDI.
E2 - System must associate a user with each TP and set of CDIs. The TP may access the CDI on behalf of the user if it is "legal".

This requires keeping track of triples (user, TP, {CDIs}) called "allowed relations".

C3 - Allowed relations must meet the requirements of "separation of duty".

We need authentication to keep track of this.

E3 - System must authenticate every user attempting a TP. Note that this is per TP request, not per login.

For security purposes, a log should be kept.

C4 - All TPs must append to a log enough information to reconstruct the operation.

When information enters the system it need not be trusted or constrained (i.e. can be a UDI). We must deal with this appropriately.

C5 - Any TP that takes a UDI as input may only perform valid transactions for all possible values of the UDI. The TP will either accept (convert to CDI) or reject the UDI.

Finally, to prevent people from gaining access by changing qualifications of a TP:

E4 - Only the certifier of a TP may change the list of entities associated with that TP.

Limitations of Clark-Wilson

This policy formulation only goes so far in protecting a system against dishonest insiders. Rule C3 requires a "seperation of duties" but doesn't specify what this means.

Another problem referred to by Ross Anderson in "Security Engineering", Wiley 2001 is that some transactions require more than one TP in order to be fully validated, e.g. a chequing account that requires 2 signatures. This can result in a pending transactions file, where there would normally be an expectation that entries in this ledger are completed or removed within a limited period of time, e.g. 3 days. Anderson describes an attack where a bank clerk siphoned money out of the system into a friend's account from a suspense account into which new transactions were continually input to cover the imbalance. Eventually the clerk responsible for the fraud became unable to keep track of the growing number of transactions. Having a rule where every bank employee has to take at least one week's holiday every 6 months reduces the risk of someone being able to maintain this kind of juggling act without being noticed for very long.


It's one thing for an organisation to keep books and records. It's another for these records to pass muster by an independant and experienced professional who comes in unannounced at any time to check them and confirm whether or not the records correspond to reality. Banks do this more frequently using internal auditors, but accounts of all organisations over a certain size will have to be externally audited once a year. In practice auditors will tend to check samples of activity. The purpose of an audit isn't to prove that a system contains no errors, but to carry out spot checks which helps encourage participants to stay honest and alert, by risking detection of any dishonesty or sloppy oversight through audit.

Financial Transaction network protocols

In any protocol that involves a sequence of messages between the initiator, or client, and the responder, or server it is possible for the last message in the protocol to be lost. In this situation the sender of this last message is in a state which assumes the transaction to be completed, while the other party is in a state which records the state of the transaction to be uncertain.

For relatively unimportant purposes, e.g. sending an email, the client might simply resend (assuming the last protocol message lost was from server to client). This can result in duplicate emails.

For financial transactions this phenomenon must not be allowed to result in missed or duplicate payments.

One solution is for the client to provide the server with a unique key field describing the individual transaction, and for the server to acknowledge this and the status of the transaction it refers to in the set (initiated, rejected, complete). If the client is uncertain about the status and reinitiates using the same unique transaction key, the response will state whether this transaction has completed. This requires the server to store the status of all recent transactions, and for the client to continue the processing of a transaction it has initiated until a rejected or completed status is confirmed, within a shorter period than the server remembers these. The period of potential uncertainty which can occur after a client has initiated a transaction before it has been completed and when the last protocol message is sent by the server but not received by the client, is a potential system weakness which needs careful design to remediate.

Three party transaction book-keeping

A wide variety of business transaction requirements exist. The security of these requires that the two main parties to a transaction (i.e. the buyer and seller) maintain and confirm their own records. Also where the payment occurs within the context of a payment reconciliation system maintained by a third party, three parties will be keeping records of the same transaction independantly.

The third party by operating a payment system acts as a transaction aggregator or payment recording intermediary, e.g. a clearing bank or stock-exchange market-maker. Another example of a third party responsible for a payment reconciliation system might be the accountant responsible for the audit of a trade credits system, e.g. as operated by a supermarket chain or airline to track discount points or air miles.

These systems are ubiquitous, but currently there is little or no integration between them, such that all these payment systems are maintained seperately, and all parties using these systems have to take responsibility to maintain accurate accounting of their own involvement and reconcile their own records kept at the time of sale or purchase against trading statements later issued by the payment system operator, e.g. the bank or market maker.

The author of these notes has specified a transaction handling infrastructure and protocol enabling the various accounts and payment mechanisms which enable individuals and businesses to share a common set of protocols, user and security interfaces, and network addressing, routing and infrastructure.

The potential security benefit of this approach, if and when it is implemented, will include the automated reconciliation of the records stored by the three parties to all relevant book-keeping transactions.

Anonymous money

Probably the most useful form of anonymous money currently is conventional cash. You don't have to know who is spending it to authenticate it when you accept it, and you don't have to say who you are when you spend it. In the early 1990ies, a number of libertarians designed, developed and campaigned for the concept of digital electronic cash. This digital money was cryptographically "blinded" so as to prevent the bank knowing who was paying how much for what, while including protocols preventing double spending of digital tokens.

David Chaum is a cryptographer who was influential in developing and patenting such a scheme and unsuccessfully attempting to market this through the DigiCash company.

One reason why anonymous digital cash might be less neccessary than advocates including Hettinga and Chaum suggest is due to data protection laws preventing unwarranted use by banks of customer records Another factor concerns the improved security the bank customer obtains precisely from the accounting carried out by the bank. Sacrificing this for anonymimity is likely to be something which few will feel the need to do other than for small payments.

The logical consequences of a thought experiment hypothetically proposing use of an anonymous payment system in connection with an assassination market makes it impossible that any electronic payment system sufficiently anonymous for this purpose could ever be developed, given the facts that:

This logic suggests that contract killers will continue preferring conventional cash or other available means of money laundering, e.g. using offshore casinos, drugs or precious metals.