Little attention is being paid to the obvious fact that today's accounting relies on record keeping in computers. Large corporations rely on huge "legacy" mainframe computers to run their databases. These legacy systems are at the root of the problem, since they are not being audited by technical systems personnel with an auditor's "eye", but by CPA's from the Big-7 auditing firms, who tend to assume that data they see in computer print-outs is valid, by definition.

A computer does not make a mistake, unless it is programmed to do so. The computer can be used to deceive even expert financial auditors, not to mention the shareholders and the general public. There are many methods that are known to be used by collusion between computer programmers and financial analysts to commit fraud, some of which follow:

Legacy databases are immense, spanning tens or even hundreds of millions of records. It is common practice for large corporations, such as insurance companies, banks and government agencies, to process millions of transactions overnight posted to accounts in these huge databases. Once a database spans millions of accounts, it becomes physically impossible to verify that the data it contains is indeed accurate, because even reading the entire database can involve more than the time window allotted for overnight processing. The database is then only a repository, it can not be used directly for reporting.

In practice, this limitation is solved by creating aggregate files with totals accrued from the detailed database. These "summary files" are then updated nightly, sorted and reported to the corporate financial systems as their input data. Rarely is there any attempt done to reconcile the entire database against "summary" files, since the amount of processing time is prohibitive. It is also not a trivial matter to do so, since some of the demographic data may change over time on the database, but the aggregate files reflect only the last demographic data values.

The summary files can be modified or adjusted at will, without having to post transactions from the database. It is common practice to reverse values and transfer totals between one demographic or financial variable and another. In effect, the financial reports reflect adjustments and other non-ledger activity which can not be verified against actual transactions on the database.

The COBOL legacy programs are at least 20 years old, and in some cases, up to 40 years old, and have grown almost organically over the years. They are referred to as "spaghetti" programs in the field, since they resemble a plate of chaotic spaghetti threads, with little structure or apparent logic. Over a period of years, numerous temporary contract programmers have added layer upon layer of modifications to the source code, and leave behind little documentation about what they have done.

It is quite simple to add hidden "back door" options or code sequences to these behemoth programs, which can only be found by qualified systems auditors. For example, a special account number can be used to provide an override or some hidden function, which is known by only by those involved in the scheme. Some accounts can be given "special treatment" and bypass the established processing standards. Non documented input controls can be used to cause some type of hidden process on the database itself.

The best way to guarantee that these types of secret code sequences are not present is to throw away the entire "bowl of spaghetti" and re-write the programs using state of the art structured object programming methods such as Java. Java is designed to provide the encapsulation necessary to prevent side effects from destroying the integrity of programs

It is possible to load a different version of a program than the source code that compiled it, by simply renaming a fraudulent program module to the authorized name. In fact, given level of access that software developers normally have at an installation, many such stealth replacements can be made.

Some of these anachronic COBOL programs have been "patched" by adding machine level code to the load modules rather than by modifying the source code. These low level modifications are only visible from program memory dumps.

 Source code modifications.

In remote distributed locations, where centralized control over the source modules is not maintained, it is common practice to modify the source code at the local level, normally to add some local procedures. It then becomes possible to run a different database update process at the remote sites, and report to the central site as if the same version of the software had been used. In practice, the source version level controls are often bypassed by developers, and they are rarely used in distributed remote processing sites.

This problem is far from trivial, since multinational corporations routinely share their source code with their overseas facilities, to allow them to add locally mandated procedures. Without a strict global source update control, there is really no guarantee that the software is free from fraudulent code sequences.

A common fraud involves creating bogus accounts and processing transactions against them, in order to give the appearance that the business is successful. Most of these transactions are indistinguishable from valid ones, except for the fact that they are not properly reconciled against the external banking systems.

In some installations, a large amount of fiat work is done by unwitting clerical staff, with the intent of creating false database transactions that will be overlooked by the external auditors.

If one wonders why none of the gigantic frauds which have been surfacing since 2002 were ever noticed by the clerical staff, it is because the amount of work and transaction flow is so large that it becomes a kafkaesque routine, and no one bothers to find out what the true intent of the work is.

We tend to assume that software running in overseas banks and other institutions has the same level of quality controls as the software than runs on our own legacy systems in the USA. This is sadly not the case. In fact, there is reason to believe that most of the offshore banking arrangements are prone to fraudulent reporting, and false deposits have been made in offshore banks for years, creating false money, which then is transferred to the USA and Europe by means of the IMF's clearing house.

Overseas systems sometimes resemble laundromats, where money is digitally created on the fly. Once it is recorded in the offshore banking databases, it's value can not be disputed.

If we can not certify the accounting systems from certain countries, then all financial activity in those countries is suspect, as are the globally accrued results reported by multinational corporations doing business in those countries. We may in fact be floating on a sea of false money, smug in the belief that our own technology and high levels of productivity have brought about our unexpected wealth, where in fact, we have been living beyond our means in a global financial bubble since the "trickle down" Reaganomics of the mid 80's.

The current practice of having the same audit firm perform both the accounting audit and the systems audit can lead to agreement where none exists. We must insure the independence of the systems audit, and regulate it within the business legal code. A systems audit must be performed at corporations and institutions of a certain size, by an independent external systems audit firm that is not a part of the external financial audit firm.

System audits should be performed by software engineers, and they must be able to certify that the reported accruals of any databases under their control is correct and true. Financial audits are the domain of the Big-7 auditing firms, whose certification should extend only to the validity of the accounting practices involved, not on the data used to post onto the ledgers.

Software developers need to adopt a code of ethics. This will become self evident as more revelations come out about the role of software fraud in financial reporting. There should be a legal framework to the software development code of ethics, with enforceable penalties set in simple but clear language.

Overseas software needs to be validated if there is any flow of funds or other information from banking and insurance systems into our own. We can not allow our own systems to be compromised by the fraudulent activities of others outside of our borders. We need to institute an international process of software quality assurance and validation similar to the ISO 9001 certification for manufacturing. We must promote the use of Java as the language of choice for the new ISO software certification.

This is a time of transition between the first generation of cybernetic systems and those which will follow. The legacy systems were developed over many years almost by trial and error, by the evolution of software processes which model the paper based accounting and financial bookkeeping systems in use for hundreds of years.

Yet, the computer has allowed these systems to operate in the vast new dimension of cyberspace, where human intervention is inadequate, and human capabilities insufficient to the task. We have let our legacy systems grow beyond their capability to be controlled by human beings, and are therefore exposing our economies to grave dangers, as we are beginning to see in 2002.

Atlanta