Cards, accounts, 2 balances

    As Raiffeisenbank debit card holders know, the card is only an access tool to the account: it does not have its own balance, only the funds available on the client’s current account are available on it. In this article we will talk about the architecture of a technical solution that allows cards and accounts in our bank to use a single balance. And also you will learn about how the project was organized, which allowed us to implement this architecture.

    To begin with, let us show by example how the “card to account” and “card in itself” schemes differ. Suppose you received a wire transfer through the banking system of the Russian Federation - compensation from the state for the birth of a child. In the “card to account” scheme, this amount becomes available for debit transactions on the card at the time the transfer is credited to your bank account. In the “card by itself” scheme, it is necessary to transfer a certain amount of money from a regular account to a card account, after which funds can be spent with a card.

    Such a seemingly elementary and logical functionality is provided by a rather complex technical solution, which is far from being successfully implemented in every bank. For example, until 2014, in our bank, debit card balances lived separately from account balances: cards in processing, accounts near ABS. Balances were synchronized in the morning of working days. Needless to say, such a scheme led to problems for customers: if a person prematurely terminated a deposit, then he could spend / withdraw money on a card only tomorrow. And if today is Saturday, then “tomorrow” turned into Monday. In those days, a good third of complaints were somehow related to this topic. Inside the bank, this implementation also led to difficulties: for any expense transaction on the account, it was necessary to check whether the client had spent the same money on the card. As a result, most systems used a software POS terminal emulator, through which the balance on the card was checked and a special blocking was placed in processing. This check did not work correctly in all cases; often, manual intervention by the operator was required. For example, the card is temporarily blocked, it has 100 rubles on it, the client withdraws 100 from the account, the POS terminal emulator gives an error for such a lock, the amount does not block. If this problem is ignored, then after making an account transaction on the account, the client will unlock the card and withdraw another 100 rubles. there are 100 rubles on it, the client withdraws 100 from the account, the POS terminal emulator gives an error for such a lock, the amount does not block. If this problem is ignored, then after making an account transaction on the account, the client will unlock the card and withdraw another 100 rubles. there are 100 rubles on it, the client withdraws 100 from the account, the POS terminal emulator gives an error for such a lock, the amount does not block. If this problem is ignored, then after making an account transaction on the account, the client will unlock the card and withdraw another 100 rubles.

    This is not a complete list of problems that the bank faced when using the previous architecture. At some point, the realization came that this architecture was holding back the development of bank services, and we decided to remake the technical implementation of “card to account”.

    The key question to answer was: in which system will the current value of the available balance live? Usually, banks have two candidates for this role - the processing system and the ABS. Traditionally, in processing, card balances live in the “card by itself” paradigm, and in ABS, current account balances. Also traditionally, both of these systems are purchased boxed solutions from major suppliers with limited customization capabilities. We decided to go the third way - to make a separate system for working with an affordable balance. Several factors inspired us to this decision.

    Firstly, the majority of “bank account” banking products (cash, interbank payments, insurance, etc.) do not live inside our ABS. These are completely independent systems that download ready-made accounting entries to the ABS.

    Secondly, we wanted to make a minimum of improvements in processing and ABS by the suppliers of these systems.

    Thirdly, the ABS mechanism itself was not used to control the balance of expense transactions with the account by these external systems.

    Historically, the bank’s operational day was arranged so that the current account balance value was calculated by a special system based on the balance at the beginning of the operational day in the ABS, transactions / postings already confirmed in the ABS, and intermediate transaction data in some transaction systems (there were three such systems ) But what about the balance control for operations that are initiated inside the ABS? After all, she cannot turn to the third system to check the balance ?! For credit products (scheduled write-offs on the payment schedule, work with late payments), the ABS uses its balance at the end of the day, since in the process all intermediate movements from third transaction systems are recorded in the ABS before the end of the business day. For transactional products (placement of deposits,

    An experienced eye will see several shortcomings in this scheme at once. This is the implementation of the calculation of the current balance outside the ABS, and the accounting in the calculation of the balance of the data of third systems (which are stored on a separate DBMS from the ABS). We tried to turn our disadvantages into advantages. The fact that the current value of the available account balance is calculated outside the ABS has several advantages. The Bank may at its discretion (without modifications to the ABS) change the balance calculation algorithms, we can somehow learn how to calculate the balance in the process of closing the day in the ABS. We’ll talk about this moment in more detail. Our ABS is built on the concept from the last century: it provides for the process of closing the day, which lasts several hours, and during which you can’t do anything with the ABS at all - either enter transactions or watch data. But if the balance is considered outside the ABS, then this problem can be circumvented!


    So, we decided on the target system, which will be the source of truth in the available balance - it will be neither ABS nor processing, but some new system. Let's call it code letters NI. Based on the above-mentioned features of the work of bank systems, for the correct implementation of the NI system you need to perform the following steps:

    • Refuse to analyze the data of transaction systems when calculating the balance (we mentioned three such systems - cash, ruble payments, and legal entity conversions). This is necessary for reliable and quick work of card authorizations, so as not to go to third-party DBMS.
    • Switch to NI all systems using the current specialized system for calculating the balance. Or connect the old system to NI, which is easier; this is what we ultimately chose.
    • To teach NI how to work somehow in the process of closing the ABS trading day.
    • Integrate NI with card processing.
    • See how all these changes will affect Internet banking.

    Refusal of these third systems when calculating the balance of the account

    How did it work? Suppose, on the client’s account at the beginning of the day in the ABS, the balance was 100 rubles. The client withdrew 50 rubles through the cashier at 10 a.m. There is an operation confirmed by the cashier in the cash register system, but the wiring for it has not yet been created in the ABS (remember that she loves to accept ABS from the past century, in large bundles, and not one by one). The cash system, according to its plan, plans to unload this and other confirmed operations with postings to the ABS at 12 noon in a single bundle. How to take into account that 50 rubles are no longer in the account balance? In the early 2000s, the bank found an “elegant” solution for this - the balance calculation system will open a connection to the base of the cash system and in it will select all operations confirmed by the cashier, but not yet uploaded to the ABS. And so on three different systems.

    Obviously, accounting for the “in the moment” operation in the available account balance, which will later be uploaded to the ABS with a bundle of transactions, is a fairly common task. The entire online banking products of the past decade and a half has been directed in this direction. It turns out that as new similar systems appear, our balance calculation system would have to be connected to each of them. This is a dead end in terms of development. We realized this when there were only three systems, and even it was difficult to cope with them.

    The solution seemed to us more correct when creating a single repository of all account movements confirmed but not yet uploaded to the ABS. And all systems that need to take their operations into account in an available balance in real time should connect to this repository through a set of APIs that should allow both calculating the current value of the available balance and changing it by creating account movements. Since they decided to call the new system NI, its API will be called the “NI API”. At the same time, our old system of calculating the available balance should learn to look into this new NI repository, and the repository itself, for the purpose of speed and reliability, they decided to place on the same system where the ABS lives. In our case, this is the IBM i platform.

    We decided to conditionally divide all movements in the account into two types: holdings and postings. Holds are locks of specific amounts in customer accounts that are not a fact that they will actually be debited. Holds can either have a validity period or be unlimited. It was planned to use this type of movements for card authorizations, arrests of amounts by decision of various supervisory authorities, and so on. Postings are account movements that have actually occurred, but have not yet reached the ABS.

    It is also reasonable to add options in the API for creating account movements that allow creating a movement only if the available balance is successfully checked. The external system, as it were, says: “Create an account transaction on the client’s account for 100 rubles if the current value of his balance allows this.”

    Imagine how in our example the cash register system should work with the NI API. The client takes 50 rubles at the cash desk at 10 a.m. The cash system applies to the NI API with a request: “Create an account transaction on a client’s account for 50 rubles if the current value of his balance allows this.” NI calculates the balance, it allows you to complete the operation, NI creates a movement of 50 rubles in its intermediate storage and answers the cash system: "Everything is fine, give it out." If the balance on the client’s account was less than 50 rubles, NI would answer: “Things are bad, the current balance value is 40 rubles.”

    It is 12 o’clock, the time has come for the cash register system to unload its bundle of completed operations by posting to the ABS. In theory, at the time of unloading operations, she should inform the NI API that these movements have already reached the ABS, and it is time to remove them from the intermediate storage of movements. And here the difficulties begin. According to the logic of the process of unloading a bundle of transactions in the ABS, one commit is made for the entire bundle. So, you also need to remove these movements from the NI repository in a bundle and with one commit. Bundles of postings can be quite large, the time interval between commits can be quite large (tens of seconds maximum, but for us this is a lot), during which the client will have an incorrect balance in the account. Technical failures are also possible when the packet commit in the ABS was successful, but in the NI API for some reason - no.

    Fortunately, we identified these risks during the design phase of the NI system. To level them, they decided to “stretch” the NI functionality to the ABS. In the API for creating postings, a mandatory field with the identifier of the bundle of postings into which the external system wants to combine these postings has been added. Also, a separate function was added, “Write a packet of postings to the ABS”, upon the call of which NI himself recorded the postings to the ABS, with a single commit in his storage and in the ABS. This was greatly helped by the fact that the NI and ABS databases were located, in fact, in one DBMS. Thus, at 12 o'clock the cash register system simply said to the NI API: "Unload the bundle of NI postings in the ABS and notify me of the problems that have arisen."

    Problems are very rare, but have arisen. For example, when a bailiff came to the bank between adding the expense movement on the account to NI and uploading this movement to the ABS and arrested the account. In such cases, the cash register system gave the user information about the problem operation, and it was necessary to handle the situation manually.

    An NI API was developed that provided several logically grouped APIs to external systems:

    • Getting information on the account (balance, statuses, and so on).
    • Work with packs (creation, deletion, unloading in ABS).
    • Work with individual wiring in bundles.
    • Work with Holds.

    Technically, the API was a set of programs written in the programming language Free format ILE RPG using SQL. To use the API outside the IBM I platform, the programs were wrapped in stored procedures based on DB2 for i, with which external systems could work using standard ODBC, JDBC, and so on. Also, access to the NI API was implemented from the corporate integration bus ESB, which, in turn, also accessed the API via ODBC / JDBC.

    Switch some systems to NI

    Since we decided to finalize the previous system for calculating the available balance so that it could work with the new intermediate repository of movements on NI accounts, we did not need to refine all the bank’s IT systems. But we needed to redo the mentioned three systems (cash, ruble payments, legal entities conversions) so that they would start using the NI API for intermediate movements, and when calculating the balance, we would no longer use the transaction data of these systems. In fact, this turned out to be a rather complicated refinement, since in each system we had to redo the main logic for processing the operation life cycle. For the ruble payment system, I had to redo the internal architecture of the system, moving from a two-link to a three-link. This was required in order to centralize the logic for working with the NI API on the application server.

    But the main difficulties at this stage were associated not only with technical and architectural, but also with business aspects. The listed systems are highly demanded by customers in terms of improvements, the backlog always has a lot of ideas for development, optimization of products and processes. The need to carry out such large-scale improvements without tangible, from the point of view of business, benefits was perceived by customers without enthusiasm. Recall that the essence of the changes was to ensure that the system for calculating the available balance ceases to go to the bases of these systems, and they themselves via the API notify the centralized NI system of account movements. For business, this is practically of no value.

    To find a way out of this situation and to persuade the business to our side, a successful set of circumstances helped us. Just at that time, a module for off-balance accounting of plastic cards was introduced in the cash system. There are many cards, their movement processes are quite complex, which means a large number of transactions on off-balance accounts. There is a significant flaw in the old mechanism for generating postings from external systems in the ABS: the posting packages created in the ABS must be accepted manually using the user interface of the ABS itself. Moreover, this can be done by a user with special rights that are issued only to a limited circle of persons. And in the aforementioned project on unbalance, there was a fierce debate between various departments about who will accept these packages, to whom what rights can or cannot be given. We have proposed a solution: in the NI API, make an option that will allow the formation of posting packages in the ABS already in accepted form. Of course, for this, the entire module must be transferred to the new API. Everyone really liked this idea, we were given the go-ahead to redo it.

    Implementing a mechanism for creating already accepted posting packages has technically proved to be quite a difficult, but interesting task. We analyzed the call stack of regular ABS programs for posting acceptance, tracked its manipulation of data with the DBMS transaction logs. As a result, we learned to trick the ABS and create an accepted posting. The cash module on off-balance sheet was launched on the NI API, transactions flowed into the ABS without an operator accepting it, and we got an understanding of how to stimulate the business to switch to NI. The secret turned out to be simple - it is necessary to offer the business during migration additional functionality that will simplify their processes or improve the product in some other way. And then the map went to us ...

    As a result, NI was overgrown with functionality for creating postings to blocked accounts (relevant for write-offs by court order and so on, in the old process, accounts were temporarily unblocked manually), with complicated options for calculating balance for priority, overdraft, and other tricks. This allowed the business to get their buns while migrating functionality and significantly streamline processes. So, the cash desk and ruble payments are done, there remained currency exchange operations of corporate clients.

    And with this system, things did not go well with us. Very few operations took place in it, there was no need for the development of functionality, optimization did not promise significant benefits. As a result, we were not able to convince partners of the need for improvements, and we waved a hand at her. Until now, when calculating the balance on corporate customers accounts, a connection has been opened with its DBMS. But then this did not upset us, because we achieved our main goal - according to the accounts of individuals, all the data for calculating the balance was concentrated in a single IBM i DBMS, the calculation worked quickly (about 5 milliseconds per account) and reliably.

    To teach NI to work in the process of closing the trading day

    Upon closer inspection, this task was surprisingly simple. Since our ABS in the process of closing the day was not able to accept any movements in the accounts, the bank simply froze at night. No account transactions were conducted. Therefore, our changes in NI did not need to be synchronized with any other systems except the ABS itself. As a result, we made minor improvements to the ABS by inserting a call to the special NI control programs at the very beginning (day-> night) and at the very end (night-> day) of the closing process of the trading day.

    The program "day-> night" simply copied the tables of the ABS necessary for calculating the balance into a separate library in the same DBMS. The primitive INSERT SELECT construct was used. All copying took about 20 minutes. After the copy was completed, NI understood that now it was necessary to go not to the ABS table, but to its copy.

    The "night-> day" program worked out instantly, simply switching NI to work with the main ABS base.

    This solution allowed to switch between the phases of the day without interrupting the service. All account movements that external systems wanted to complete during the close of the ABS day were accumulated in NI. Further, after the opening of the ABS day, external systems had to give a command to upload the postings to the ABS via the NI API. This is not very convenient for external systems, so the STP mechanism (from straight through processing) was later created, in which the external system only creates the wiring in NI, and then it itself groups them into packets and unloads them in the ABS when it is for this available.

    The implementation of the day-night scheme is not without grace. We used the full-time IBM i contextual engine — a list of libraries. Two libraries were created - day and night. They created aliases for day and night copies of the ABS tables, respectively. For each table and its nightly copy, the alias name matches. All SQL expressions used only aliases to access the ABS data.

    Before processing each call, the NI API looks into a special Data Area object (very read-write) of the IBM i system to see if the mode has changed from the last API call in this process. As you might guess, the mode in the Data Area changes the program day-> night and night-> day. If the mode has changed, the program simply replaces the library with aliases in the list of process libraries; this is an extremely fast operation.

    As a result, all NI API client systems were able to calculate the balance and conduct operations 24 hours a day without interruptions, not really worrying about the operational day in the ABS. For us it was a revolution.

    On this we did not stop the development of the logic of the night / day transition. Those 20 minutes to copy tables using SQL did not give us rest. A replication scheme was invented and implemented using the MIMIX High Availability solution. The idea is that a night copy is not created at the moment the ABS day closes, but when the day is opened. During the day, this copy in near real-time mode is synchronized with the ABS data. And in order to be ready for any blows of fate, we do replication on two IBM i systems at once: primary and backup.


    At the moment, we go day-> night and back almost instantly, the service is not interrupted for a second.

    Integration with bank card processing

    As you know, the life cycle of a bank card transaction consists of two main stages: authorization and clearing. However, in some cases, authorization may not be.

    From the point of view of the available balance, during authorization it is necessary to check the available balance on the client’s account, block the transaction amount with a “hold” and reply to the payment system about its decision: approved or not. It is also advisable to send a notification about the operation to the client, but we will consider this in the chapter on Internet banking. When clearing, you must try to find the hold that was set earlier during authorization, delete it and create a posting to the client's account.

    At the time of the start of the project, our processing system was able to apply for authorization to check the available balance in external systems. This functionality was created earlier, when combined with Impexbank, since Impex had a card-to-account product. In the process of authorization of the operation, after the completion of purely card checks (cryptography, PIN-code, etc.), the authorization system sends an ISO-8583 message to the external system for financial authorization and waits for a response for a certain number of seconds. We were required to create a special NI module that could communicate with the processing system using this protocol. Receive a message, parse into fields, call the NI API, form a response. A fairly simple task, but only at first glance.

    The first difficulty awaited us with online operations to replenish the client's account using a bank card. These are payments to ATMs and incoming transfers from card to card. According to the logic of these operations, authorization and clearing can take place on different banking days. Suppose a client with a zero balance in the account receives a transfer from a third-party bank on April 1 at 10:00. At 10:05, the client allows these funds for early repayment of the loan. Clearing for this operation will arrive on April 2. If on April 1 (during authorization) we do not make an accounting posting with account replenishment, but simply raise the balance with a “positive hold”, then after repaying the loan in the account there will be a negative balance, a technical overdraft, which will close only after clearing is received. In banking, technical overdrafts are avoided in every way,

    From the first complexity follows the second - exchange rate differences. When a transfer comes from a foreign bank, the amounts during authorization and clearing may vary due to currency fluctuations. We illustrate with a real example. On June 11, our client received a card transfer from a Belarusian bank, the transfer amount is 15.00 Belarusian rubles. The Bank is physically unable to support conversion rates to all currencies of the world for card transactions, we conduct rates in three currencies - rubles, dollars, euros. The authorization payment system recalculates the amount of the transfer at its own rate to the issuer's currency, in this case it was Russian rubles, the amount was 455.50. The client’s account is open in rubles, so we spent 455.50 rubles on arrival. From this moment, the client can manage this money as desired.

    On June 14, clearing from the payment system came to us, and EUR 7.16 was transferred to our bank for this operation. From the point of view of accounting, it turns out that we conducted a conversion operation distributed over time: we bought 7.16 Euros for 455.50 rubles. It would be nice to understand if the bank earned on such an operation or lost. According to our rates for June 14, it turns out that we would buy 7.16 euros from a client for 445.35 rubles. So, the bank was unlucky and he lost 10.15 rubles. It happens that it is lucky, and the bank makes money on fluctuations. The technical implementation of such a calculation scheme is very complicated. Why fool yourself, you ask, because such operations with currency risk can simply not be shown to the client in the balance sheet before clearing. In addition, there are relatively few such operations. To be honest, some banks do so. But our motto - “difference in attitude” does not allow us to do this.

    The third difficulty we came up with for ourselves. Our processing system does not know how to calculate transaction fees at the time of authorization. She considers these commissions offline when clearing arrives at the bank a few days later. Accordingly, the client does not see the amount of the commission in SMS during the transaction, it suddenly appears in the statement a few days later. Following the tactics of implementing additional functionality, we took on board the calculation of these commissions. This entailed the creation of replicas of the tariff tables from the processing system, the repetition of the logic for calculating the commission, special screens for answering customer questions, and so on. But as a result, our customers immediately see the amount of the commission in the authorization SMS and in the statement.

    With authorization sorted out, go to clearing. In the previous scheme of work, a special intermediary system took clearing operations on customer accounts from the processing system, turned them into accounting entries and stored them in the ABS. Moreover, at the time when our project reached processing, this intermediary system was already working with the NI API (the NI bonus in the form of automatic acceptance of posting packages stimulated business owners of systems to make such a transition). At the time of clearing, our main task is to find authorization in NI, remove the hold from it and complete the posting. But the accounting entry data is not enough to search for authorization. We saw two options for implementation:

    • Create a separate API to search for authorization and withdrawal of a hold.
    • Embed card transaction data in the “wired” API, so that in one call and posting, add and remove the hold.

    After much deliberation, we discarded the first option, since it assumed two calls to the NI API — to search for authorization and add wiring. There is a risk that if the first call is successful, then the second one for some reason breaks. Then the client will be removed from the hold, and the posting will not be added, and the balance will be overestimated with all the ensuing consequences. For card clearing, we made a wrapper program over the NI API to add transactions. In this wrapper, additional fields specific to card operations have appeared. Based on the data from these fields, NI searched for authorization, understood what the processing scheme was at that moment, on the basis of which either created a transaction or modified it (for example, for the case of incoming transfers). From the point of view of the intermediary system, the improvements are minimal.


    Changes in Internet Banking

    Two things are interesting on the topic of Internet banking: look at the card / account balance and the statement. Prior to the project, these entities for debit cards and their accounts lived in an Internet bank separately. It was impossible to see the current value of the balance of accounts, only the balance at the beginning of the day from the ABS was displayed. The account statement was also taken from the ABS over the past days. Today, a payment has arrived in your account? See in internet banking tomorrow!

    On the cards, customers saw the real balance and real lists of operations. But what a technical implementation was behind it! The Internet Bank constantly, every two minutes, turned to the processing base, taking from it fresh authorizations on cards and changes in card balances. He put all this in his base. Since balances from the ABS were loaded into the processing once a day, the Internet bank caught this event in the processing logs and began a massive overload of the balances of all cards and active holdings. This procedure took a long time; while she was walking, clients could see incorrect information.


    With the transition to NI for Internet banking, everything was simplified. He stopped going to the processing base, stopped loading balances and postings on accounts from the ABS. When the page is displayed to the user, the Internet Bank through the NI API requests balances and statements on cards and accounts. Now customers always see relevant information. In fact, we have moved from strong connectivity at the database level of the Internet bank with the ABS and the processing system to a service-oriented architecture.

    Separately, we promised to talk about SMS informing upon authorization by card. Prior to the implementation of NI, SMSs were generated in Internet banking systems upon receipt of fresh authorizations from the processing database. In this project, we tried to implement an event-driven architecture. Especially for NI, a topic was created in the IBM WebSphere MQ queue management system. NI publishes in this topic all the events related to a change in balance: a hold appeared, a posting appeared, the hold retired, and so on. At the same time, event attributes are displayed in the message headers, which allows subscribers to flexibly select only those events that they need. The system of SMS-informing customers was the first to connect to this topic, customers began to receive messages faster. Our employees participating in the pilot even complained that the new SMS scheme comes faster,

    The results of the experiment with event-driven architecture were recognized as extremely successful, inside the bank this approach is now applied in a wide range of tasks.



    Having implemented such a large-scale project, the bank was able to eliminate a number of architectural flaws in the processes of processing transactions and displaying information for customers, which created a powerful base for the development of products. Following individuals, this functionality was demanded by corporate clients. Business 24x7 special cards were issued, in which the emphasis is on the general balance of the account / card. The Internet bank for legal entities has also acquired online services.

    Well, now you know what is behind your Raiffeisenbank card, and how we relate to reliability and customer experience. And that we have transfers to the cards credited to the account instantly!
    Some dry statistics:

    • About 70% of transactions in the bank are formed through NI.
    • The API for the balance request is called on average 5 million times a day, on peak days it reaches 8. Approximately half of all requests are accounted for by RBS (display of information to customers).

    Also popular now: