Why companies do not know how to handle money

It so happened that my career — first a developer, then an architect, a technical director, and finally an entrepreneur — developed primarily in the near-financial sector. Most of my professional activity has been in designing and writing software for banks, broker companies and similar companies. On one of the most typical technical problems of the financial sector, I would like to tell the respected habravchanam.



In the public mind, the image of a banker, trader or broker is very enviable. This person is the master of life in an expensive suit, dissecting it in a brilliant powerful machine, unshakably confident and possessing some kind of mystical economic knowledge. Knowing exactly what and how to do, so that the money that he and hens do not peck at, turns into an even bigger pile of money.
')

With the help of its trading terminals, BI systems, risk management systems and other frighteningly ingenious software, this incarnation of a businessman’s archetype can do fantastic things - for example, predicting the future of markets, earning on quotes and courses movements. Perhaps he can, with frightening accuracy, calculate his risks, guaranteed to stay in the black, or create another, inaccessible to mere mortals, financial magic.

Needless to say, most people are confident that this successful financier knows exactly how much money he has at the moment. As well as how much they owe him, and to whom and how much he owes. At any moment, his reliable, uncritical software (after all, these are systems where money sits in almost every variable!) Will provide him with this information in all its details and cuts. Upon first request, it will give all the necessary numbers and draw beautiful graphics in real time.

Those of you who have worked in financial and similar companies, and have dealt with the core code (Core Banking, OLTP or their equivalent that sells financial products) - they are surely grinning unkindly, remembering something of their own. Because the reality is infinitely far from the picture that arises in the imagination of the average person when he hears the phrase "financial company."

The bitter truth is that companies managed by these sharks of business in expensive suits, in most cases, only very approximately can find out how much money they have at the moment and what happens with this money (and, therefore, with the company) right now.

Behind the façade of gloss, solidity and professional expression, there is often confusion in reports, errors in customer accounts, system failures, an inconsistent balance in accounting and nervous curses by developers trying to make the code for this entire enterprise work. To understand why this is happening, consider the simplified business process and its implementation in most financial institutions.

A typical process in a typical financial company proceeds approximately as follows: Customers interact with the online system, changing the balance values ​​in its account (by depositing and withdrawing funds, as well as using financial products that change the state of the account). These operations are performed by a system, scientifically called OLTP - Online Transaction Processing, designed to perform certain operations with accounts on the fly, thus realizing the company's business.

In the overwhelming majority of fairly complex and loaded systems, OLTP can neither provide data for the reporting system, nor even answer the question “how much money is currently in the system and how it is distributed” until the EOD is produced. EOD - End Of Day, a set of procedures that serve to close the accounting day and get financial results on it, as well as to calculate the company's financial products. For example, in most banks, it is during EOD that interest is calculated on customer deposits. EOD is performed in the system, as a rule, during non-working hours - at night. In this regard, many Internet banks, depending on their technical advancement, are partially or completely unavailable at night.

Thus, with a standard and universally accepted approach to the design of financial systems, the profit per day can only be assessed after the EOD and all its procedures. In addition, to get results for a closed day, live people are often involved - for making amendments, entering coefficients - in a word, for everything that is not yet automated or has the character of “temporary nuances". For example, if you need to consider not only the results logic within its own system, but also the state of the company's accounts for counterparties that are not connected to the system through the API.

The result of this whole process - accountants spend a lot of time to reduce a non-convergent balance, the profit of an international financial company, taking into account all the amendments, is often considered to be in Excel, reports generated by the system show figures that are more indicative. The figures obtained in his system, as a rule, converge with the results of counterparties only approximately, with a certain error - this situation is considered to be normal. It is bad when they do not converge at all, which also happens - in such cases it is customary to agree, and not to specify the calculation method. Here we come to the main point, namely, to the consideration of one of the reasons why this happens.

Imagine that we have a fairly experienced and professional programmer (or development team) who was given the task to implement a certain financial product. For example, a term deposit - i.e. the code must ensure accrual of interest on the deposit that meets the conditions of the agreement concluded between the client and the bank. The terms and conditions of the contract programmer receives in the form of technical specifications. The developer (or analyst) compiles a model based on the text of the task (at best, perhaps he will simply write down some valuable instructions for the programmer with the text) and proceed to its implementation in code. The code, greatly simplifying, ultimately boils down to replacing a certain value in the database with a new, calculated value. Something like

UPDATE accounts SET account_value = v_new_account_value WHERE customer_id = v_customer_id; 

The value of the field account_value is replaced with a new one, obtained as a result of the work of the created business logic. This means that the client will see the correct status of his account in his Internet bank. And this, quite logical and working implementation, opens the door to hell.

Consider this line more closely in terms of the concept and philosophy of the entire system. We put money into the account of the client, which came as if from nowhere - from the formula and model, from the resulting code of business logic. What, as we understand, is not an adequate reflection of the real world - in the Newtonian space objects do not appear from nowhere and disappear anywhere. They only move in space, as well as change their shape and condition.

As practice shows, gradually, with the increasing complexity of the system and its functionality, code size and integration with other systems, disparate operations with money coming out of nowhere and disappearing into nowhere will NEMINUALLY lead to errors, failures in business logic and, as a result, to catastrophic financial problems. and reputational loss of the company.

In addition to these dangers, the numbers are replaced by a wide variety of disparate and disconnected blocks of business logic that require long EOD procedures, if only to simply collect the resulting figures in a heap and try to issue at least some kind of report based on them. That is why business expects from IT reports for yesterday to understand what was happening with the company's business at least a day ago.

Meanwhile, the problem of money confusion and misunderstanding of the state of one’s own business is not new to humanity. Venetian merchants in the renaissance period faced the same problem. With the growth of trade turnover and the number of transactions, the old principles of doing things “on the fingers” were no longer valid. As a result, merchants had exactly the same problem as the modern financial sector (yes, these guys are in expensive suits) - confusion in numbers and the lack of a clear understanding of how much money and in what form they have at the moment.
The traders problem got its solution back in 1494, when the Franciscan monk Luca Bartolomes Pacioli published his treatise “Summa de Arithmetica, Geometria, Proportioni et Proportionalita”, or rather, its chapter “De Computis et Scripturis” (About Counting and Writing) which gave clear instructions on how to do business in books, as well as “As a merchant, without delay, get information about his assets and liabilities”. Since this event, the principle of double entry, commonly used and being the basis of all modern accounting, has its history.

The IT problem for the financial world is that developers, and even architects, for the most part, rarely know about the Franciscan monk and the principles he described. As a result, we get the systems on which the financial business depends, but at the same time suffering from the troubles that have been successfully solved in the Renaissance.

Returning from the cultural heyday of today, we can avoid such a sad situation with IT if we comprehend the process of implementing business logic not through changes in values ​​in selected fields of the database, but as an implementation of accounting approach in business logic. In this case, we enter into OLTP all the attributes present in the double entry, first of all - debit and credit. With this approach, absolutely all transactions with accounts are realized through accounting entries or in other words, financial transactions. (It is important not to confuse the considered financial transactions with the term “transaction” in programming. A financial transaction is the movement of funds or assets between accounts within the system).

Using the principle of double-entry directly in business logic, we dramatically increase the reliability and adequacy of our system, because we exclude a situation where money simply appears and disappears as a result of UPDATE. We perform all operations with accounts by postings, i.e. transfer of funds in the system. And this means that we have dramatically brought our model closer to the real world. In addition to the dramatically increasing reliability due to the constantly guaranteed balance of balance (which means huge savings on the manual labor of accountants), we have at its disposal the full power of the General Ledger and the accounting approach to working with numbers and reports.

Due to this approach to the implementation of the core business products, reporting is simplified both in terms of development and in terms of workload. This opens the way to the implementation of the EOD-free system, which is also capable of producing reports in real time - which means that business will no longer be excited to expect the results of yesterday. Instead, he will have information at the moment, and accordingly - to feel much more confident, to be able to act much more efficiently than before.

The architectural core, in which the principle of double entry is rigidly implemented, can be used to implement almost any financial and near-financial products on its base - in Core Banking, OLTP, Wealth Management, Treasury, Accounting, Payment Processing, ERP systems and any solutions operating some assets. Having a similar core in the form of a separate basic architectural layer on which the rest of the functionality is based, we not only greatly increase the security of the entire system, but also achieve a serious reduction in costs while simultaneously improving the quality in developing new products and services.

Having seen enough of how companies run in circles around the old rake, my colleagues and I decided to create our own company and started developing such a core, as well as projects and systems based on it, in accordance with the peculiarities of the customer's business. The described principle is only one of many others that form the basis of our product. If the article arouses interest and positive discussion, I will continue the story about other typical horrors and troubles of the financial sector, as well as the proposed ways to solve them.