It just so happened that my career, starting from being a developer, then moving on to working as an architect, a CTO, and, finally, an entrepreneur, has been evolving mainly in the near-financial sector. The largest part of my professional life has been spent on designing and developing software systems for banks, broker companies, and other similar businesses. And from my background, I faced some typical technical problems in those companies that I would like to talk about.

In the public opinion, the image of a banker, a trader, or a broker is a very desirable one. A person like that is a real owner of life, wearing an expensive suit and driving a shiny, powerful car; this person is unshakably self-confident, possessing some mystical financial knowledge. He knows exactly what he needs to do to earn even more money than he has, even though he is dripping with it already.

With the help of his trader terminals, BI systems, risk management systems, and other dauntingly dodgy software, this embodiment of the archetype of a businessman can do fantastic things, for example, tell the future of the markets, making money on the fluctuations of quotations and prices. Perhaps he can even assess his risks with daunting precision, benefitting in any case, or crafting some other financial magic that is inaccessible for mortals.

Of course, the majority of the people believe that this thriving tycoon is definitely aware of exactly how much money he has at every given moment. And he also knows how much he owes to others or what others owe him. His flawless, reliable software (these are the systems, every variable of which is dripping with money!) will provide this information to him in full detail, from every single perspective. It will show him the figures and draw beautiful diagrams in real time at his first request.

Those of you who have been working at financial and other similar companies and have been dealing with business logic implementation in a role of business or development (Core Banking, OLTP, Brokerage or similar financial products software) must be leering at this point, remembering incidents from your own experience. Because the reality is very far from the beautiful image that comes up in the imagination of a common person when he/she hears the expression “a financial company”.

The bitter truth is that the companies managed by these business sharks wearing expensive suits in the majority of cases can only get a very vague idea of how much money that have at a given moment, and what is happening with the money (and, consequently, with the company) right now.

Behind the polished facade and presentable and professional look, there is often a confusion in reports, errors in customers´ accounts, system downtime, mismatching balances in accounting, and cursing developers who are trying to put to work the code governing all of those aspects. To understand why this is happening, let us have a look at a simplified business process and its implementation in the majority of financial institutions.

A typical process in a typical financial company looks something like this: Customers interact with the online system, making changes in their account balance (depositing or withdrawing money and using financial products that change the account state). These transactions are done by the system that is called OLTP, i.e. Online Transaction Processing, which is used for making certain account transactions on the fly, making business work.

In majority of complex financial systems, OLTP is not able either to present the data for the reporting system or even provide the answer to the question “How much money is there in the system right now, and how is it distributed?” until EOD. EOD, End of Day, is a set of procedures used for closing the banking day and generating daily financial results, and also for calculating the financial products of the company. For example, in the majority of banks, it is during EOD that the interests on the customers´ deposits are accrued. As a rule, EOD is done outside working hours, mainly at night. Because of that, many Internet banks, depending on the level of their technological advancement, are partially or completely unavailable at night time.

Consequently, with a standard and widely acceptable approach to designing financial systems, the amount of daily earnings can only be assessed after the EOD and other relevant procedures are done. Besides, manual work is also quite often involved in obtaining the results for the closed day, i.e. for making corrections, entering coefficients, etc. To put it in a nutshell, people do the transactions that have not been automated or are of “temporary nature”. For example, if not only the results of the business logic operation inside the system, but also the state of accounts of counterparties, should be taken into consideration, which are not connected to the system through API,.

The outcome of this whole process is that the accountants spend huge amounts of time trying to strike the mismatching balance, the profit of international financial companies is often calculated in Excel, and the reports, which are generated by the system, show the numbers that are rather of an indicative nature. The numbers the company gets in its system only partly match the results that the counterparties get, usually with some level of divergence, and a situation like that is regarded as normal. It is quite unfortunate if the numbers do not match at all, which can also happen from time to time. In this case, it has become common practice to negotiate and come to an agreement, instead of specifying the calculation methods. And here is our main point, i.e. trying to understand why this is happening.

Let us imagine that we have an experienced and professional programmer (or a team of developers), who has been assigned the task of developing a certain financial product. For example, a time deposit, which means that the code has to accrue the interest on the deposit that corresponds to the terms and conditions of the contract which was concluded between the customer and the bank. The programmer gets the terms and conditions of the contract as a Business Requirements Document or set of User Stories, depending on development methodology. On the basis of the terms and conditions, the developer (or the analyst) makes a model (at its best. Maybe, he will just prepare some text instructions for the developer) and proceeds to implementation in code. In the end, simplifying the process considerably, the code comes down to replacing a certain value in the database with a new computed value. Something like this:

UPDATE accounts SET account_value = v_new_account_value WHERE customer_id = v_customer_id;

The value in the account_value field has been replaced with a new one that was obtained in the result of the business logic operation. It means that the customer will see the correct account statement in his Internet bank or other online system. And this implementation, which is quite logical and functional, opens the door to hell.

Let us have a closer look at this line from the point of view of the concept and philosophy of the whole system. We have deposited the money into the customer´s account, which sort of came out of nowhere, i.e. from the formula and the model, from the code of the business logic that we have generated. It is obvious that this is not an adequate reflection of reality, because in Newtonian space, objects do not come out of nowhere and do not vanish into thin air. What they do is move in space and change their shape and state.

As time goes by, the system becomes more complex, the range of its functions increases, its code expands, and it becomes integrated with other systems. Now, as practice shows, isolated operations with money coming from nowhere and vanishing into thin air in different parts of code and different systems will INEVITABLY lead to errors and disruptions in the business logic and, as a result, to dramatic financial and reputational losses for the company.

In addition to the threats listed above, the numbers that are adjusted by isolated business logic blocks of different kinds require long EOD procedures, at least to put the obtained numbers together and try to generate some kind of report on their basis. This is why companies have to wait for reports from yesterday in order to understand what was happening with the company at least one day ago.

Meanwhile the problems of confusion with money matters and misunderstanding the current state of one´s own business are not at all new for humanity. Merchants in Venice encountered the same problem during the Renaissance. As the trade volumes and the number of transactions were increasing, the old way of making calculations “using one´s own fingers” was no longer acceptable. In the end, the merchants encountered the same problem the modern financial sector is facing at the moment (yes, these same guys in expensive suits), i.e. confusion with numbers and lack of clear understanding of how much money and what assets businesses have at any given moment.

The merchants´ problem was solved way back in the year 1494, when the Franciscan friar Luca Bartolomes Pacioli published his treatise “Summa de Arithmetica, Geometria, Proportioni et Proportionalita” (Everything About Arithmetic, Geometry and Proportion), particularly one of its chapters “De Computis et Scripturis” (Of Reckonings and Writings), which provided clear instructions about how to record transactions in the books, and also “give the trader without delay information as to his assets and liabilities.”. That publication laid the foundation for the double entry accounting system, which is universally applicable and serves as the basis for the modern accounting system.

The IT problem of the financial world is that the majority of developers, and even architects, are hardly even aware of that Franciscan monk and the principles he was writing about. As a result, at the core of the financial business there are the systems which still have the issues that were successfully resolved during the Renaissance.

Coming back from the age of the Cultural Renaissance to the present day, we can indeed avoid this unfortunate situation with IT systems if we manage to comprehend the of business logic implementation process not through changing the values in certain fields of different databases, but as the implementation of the accounting approach. In this case, we should enter all of the concepts contained in the double entry paradigm into OLTP, and, first of all, debit and credit. This approach will allow to implement all of the account transactions through accounting entries, or, in other words, through financial transactions. (It is important for financial transactions not to be confused with the term “transaction” in programming. Financial transactions are transfers of funds or assets between accounts within the system).

Using the double entry accounting system in business logic, we will be able to increase the reliability and adequacy of the functioning of our system considerably, i.e. we will rule out the situation when the funds inexplicably appear and vanish after updating. All account transactions are registered through making accounting entries, i.e. transferring the funds within the system. It would clearly mean a considerable approximation of our model to the real world. In addition to a dramatically increased reliability level, through the permanently guaranteed matching balance (which means huge savings with respect to the work done by accountants manually), we will come into possession of the entire might of General Ledger and the accounting approach, which will help us to be more efficient in working with numbers and reports.

In result of using this approach in core of business products, the process of making reports will be simplified both in terms of development and system performance. In its turn, this will open up the way to the implementation of the EOD-free system that will also be able to generate reports in real time, which means that business will no longer have to wait for the results of the previous day in huge agitation. Instead, they will come into possession of the real-time intelligence, and, consequently, feel much more confident and be able to act more efficiently than ever before.

The architectural core, in which the double entry accounting approach is strictly implemented, can be used for the implementation on its basis of almost any financial and near-financial products, e.g. Core Banking, OLTP, Wealth Management, Treasury, Accounting, Payment Processing, ERP, and other solutions that perform transactions with different kinds of assets.

Being in possession of a core like that, in the form of separate architectural layer that underlies all other functionality, we will not only boost the security level of the entire system, but also reduce the costs of development dramatically, boosting the quality of new products and services at the same time.

After getting an eyeful of companies running around in circles and falling into the same old trap, my colleagues and I have decided to establish a company of our own, named Make IT Work, and start developing core like the one I have described already, named FEHU. We create systems for our customers on the basis of FEHU, according to the peculiar features of a customer´s business. With a large number of others know-how, the main aim of our development is to provide the financial sector with the stability it needs so much as well as confidence in numbers. Our second goal is to provide to business the opportunity for efficient development of new products, services and functionality, because according to our philosophy, the main part of business logic is covered by unified core – FEHU.