WO2020157192A1

WO2020157192A1 - System and method for processing underlying transactions

Info

Publication number: WO2020157192A1
Application number: PCT/EP2020/052284
Authority: WO
Inventors: Oliver GAZON; Gérard DETHIER
Original assignee: Value Creation Europe Sprl
Priority date: 2019-01-31
Filing date: 2020-01-30
Publication date: 2020-08-06

Abstract

A computer system (1) for processing Underlying transactions (22) between a plurality of debtors and a plurality of creditors comprises a plurality of processors (10) configured to store a plurality of sub-registers (SR). Each sub-register (SR1, SR2, SRn) is associated with one particular Underlying and stores for a particular holder the amount of the particular Underlying owned by the particular holder. A transaction request (22) is processed by applying a lock on the transaction-related sub-register (SR1, SR2, SRn) of the debtor, crediting the transaction-related sub-register (SR1, SR2, SRn) of the creditor with the transaction amount of the particular Underlying defined in the transaction request (22), cancelling the lock applied on the transaction-related sub-register (SR1, SR2, SRn) of the debtor, and debiting the transaction-related sub-register (SR1, SR2, SRn) of the debtor with the transaction amount of the particular Underlying.

Description

SYSTEM AND METHOD FOR PROCESSING UNDERLYING TRANSACTIONS

Field of the Invention

The present invention relates to a computer system and a computer-implemented method for processing Underlying transactions. Specifically, the present invention relates to a computer system and a computer-implemented method for processing transactions of Underlying between a plurality of debtors and a plurality of creditors related to a plurality of different Underlying.

Background of the Invention

Stock exchanges receive millions of transaction requests per day from different financial institutions and investors. A transaction relates to a change of ownership of a given Underlying U. Specifically, a Party A, owning a given amount of units of Underlying U requests the transfer of Y units of Underlying U to Party B. In the known processing and registration systems, the processing of a single transaction related to a particular Underlying, an 'Underlying transaction', consists of:

1 . Validating the transaction by checking that the amount of units of Underlying to be transferred by the Party A is actually owned (or borrowed) by the Party A, i.e. whether Yis smaller or equal to X,

2. Debiting Party A with Yunits of Underlying, and 3. Crediting Party B with Yunits of Underlying.

In the present context, an Underlying is based on or backed, for example, by a share or future of a stock, a country's Government bond, or a share or future in a commodity, etc. In the known processing and registration systems, a Register of Ownership (or 'Register') is used as a data structure for implementing the Underlying transaction processing described above. This Register is a collection of entries, whereby each entry represents an Underlying transaction, i.e. a change of ownership for a given Underlying. An entry in the Register comprises the fields indicated below in Table 1 :

Table 1

For checking a transaction's validity, the amount of units of Underlying owned by the transferring party A (its Ownership Status') must be computed. This is done by:

- Iterating over the Register's entries related to the given Underlying U and party A, i.e. reviewing the entries related to Underlying U where party A is either a transferee or a transferor; and

- Adding or subtracting, respectively, the amounts recorded in the entries of the Register to calculate the amount of Underlying owned by party A, thereby determining the ownership status of the party A with regards to Underlying U, prior to executing the transaction. During transaction validation, no new entry involving the respective Underlying U must be added to the Register, otherwise inconsistencies could arise, e.g. a negative balance with a negative amount of units of Underlying attributed to the party A or double spending. Because of the large number of transactions submitted per second to the processing and registration system, parallel processing of the Underlying transactions is implemented, using several Processing Units (CPUs, GPUs, servers, etc.) which are configured to process the Underlying transactions concurrently. As illustrated in the prior art system of Figure 1 , the Underlying transaction requests 22 are received from numerous external transaction entities 2, e.g. financial investors who submit transaction requests 22 directly or centralizing entities, such as stock exchanges, financial institutions, government agencies, etc. which receive and forward the transaction requests 22 to the computer system 3 of a known processing and registration system. As illustrated schematically in Figure 1 , the computer system 3 of a known processing and registration system comprises a plurality of processors 30 ('processing units' ) for processing the Underlying transaction requests 22 concurrently and recording the Underlying transactions in the Register 32 implemented in the data storage system 32 of the computer system 3. Despite the parallel processing of the Underlying transaction request 22 by the plurality of processors 30, the Register 32 of the known processing and registration system prevents the parallel processing of transactions related to the same Underlying because the validation of a single transaction in the Register 32 blocks the validation of other transactions related to the same Underlying. In the known processing and registration systems, the number of transactions that can be processed in parallel is therefore limited by the number of different Underlyings. Flowever, the number of different Underlyings is typically lower by several orders of magnitude than the number of transactions to be processed concurrently. Consequently, in the known processing and registration systems, the actual processing of transactions is deferred, i.e. the received Underlying transaction requests are queued for later processing. Actually, the Register 32 of the known processing and registration systems hinders the real-time processing of Underlying transactions. Therefore, in the known processing and registration systems, the Underlying transaction requests are queued during the day and processed by night during several hours, after the closing of the stock exchange. Another problem of the known processing and registration systems is that the complexity of computing the Ownership Status from the data stored in the Register 32 increases over time and with the number of transactions recorded in the Register 32, which as a consequence leads to increased complexity and processing overhead of validating transaction requests, because the number of entries that need to be iterated and reviewed increases each time a new transaction is executed.

US 201 5/01 2751 1 describes a system for a trading platform which increases system performance by matching orders sent by traders in parallel. The trading system of US 201 5/01 2751 1 processes and matches orders which specify either a desire to buy or to sell a quantity of a particular Underlying at a particular price. Thus, the trading system of US 201 5/01 2751 1 improves the transaction processing of orders which define an intent to buy or an intent to sell an Underlying but do not comprise an inherent transfer of ownership of the respective Underlying. The trading system of US 201 5/01 2751 1 does not relate to parallel processing of the transfer of ownership of an Underlying in a register.

WO 2008/082557 describes a system for processing and settling payment instructions related to financial instruments. While the payment system of WO 2008/082557 makes it possible to process payment instructions related to different types of transactions, it does not relate to processing the transfer of ownership of an Underlying in a register. Summary of the Invention

It is an object of this invention to provide a computer system and a computer- implemented method for processing Underlying transactions, which computer system and a computer-implemented method do not have at least some of the disadvantages of the prior art. In particular, it is an object of the present invention to provide a computer system and a computer-implemented method for processing Underlying transactions, whereby the parallel processing of Underlying transaction requests is improved and determining ownership status is expedited.

According to the present invention, these objects are achieved through the features of the independent claims. In addition, further advantageous embodiments follow from the dependent claims and the description.

A computer system, for processing Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlying, comprises a communication circuit configured to exchange data with a plurality of external transaction entities via a communication network, a data storage system, and a plurality of processors connected to the communication circuit and the data storage system. The plurality of processors are configured to execute the steps of: receiving from the external transaction entities a plurality of Underlying-related transaction requests via the communication network, each transaction request defining a specific amount of a particular Underlying to be transferred from an identified debtor to an identified creditor; processing received transaction requests; and respectively transmitting to the external transaction entities transaction confirmation messages via the communication network, upon completion of the processing of the received transaction requests.

According to the present invention, the above-mentioned objects are particularly achieved in that the processors are configured to execute the steps of: storing in the data storage system a plurality of accounts and a plurality of sub-registers, each account storing for a particular holder the sub-registers associated with the particular holder, and each sub-register being associated with one particular Underlying and storing for the particular holder the amount of the particular Underlying owned by the particular holder; and processing a received transaction request by applying a lock on the transaction- related sub-register of the debtor, associated with the holder identified as debtor in the received transaction request and associated with the particular Underlying defined in the received transaction request; subsequently to applying the lock, crediting the transaction- related sub-register of the creditor, associated with the holder identified as creditor in the received transaction request and associated with the particular Underlying defined in the received transaction request, with the amount of the particular Underlying defined in the received transaction request; subsequently to crediting the transaction-related sub register of the creditor, cancelling the lock applied on the transaction-related sub-register of the debtor, and debiting the transaction-related sub-register of the debtor with the amount of the particular Underlying defined in the received transaction request, for the completion of the processing of the received transaction request.

Separating and dividing the registration of ownership of Underlying into sub-registers associated in each case with one particular Underlying and one particular holder makes it possible to validate and process Underlying transactions in parallel without limitation by the number of Underlyings as in the known Register-based systems of the prior art, while maintaining data consistency and preventing double spending. The unlimited parallelization increases system and performance scalability and makes it possible to execute transaction validation in real-time, i.e. without requiring queuing and off-line processing as required in the known Register-based systems of the prior art.

In an embodiment, the processors are configured to apply the lock on the transaction- related sub-register of the debtor by blocking the amount of the particular Underlying defined in the received transaction request. Applying the locks selectively on transaction relevant amounts of Underlying rather than on the complete set of records related to an Underlying makes possible parallel processing and validating of a plurality of transactions related to the same Underlying. Transaction requests related to the same Underlying can be processed concurrently, making off-line processing of transaction validation unnecessary.

In an embodiment, the processors are configured to check validity of the received transaction request, prior to crediting the transaction-related sub-register of the creditor, by determining for the transaction-related sub-register of the creditor a current balance of the particular Underlying defined in the received transaction request, whereby the amount of Underlying blocked in the transaction-related sub-register of the debtor is subtracted in the current balance, and not executing the received transaction request, if the current balance of the particular Underlying is below the amount of the particular Underlying defined in the received transaction request.

In an embodiment, the processors are configured to execute concurrently the processing of a plurality of the received transaction requests.

In an embodiment, the processors are configured to apply the lock on the transaction- related sub-register of the debtor by storing in the transaction-related sub-register of the debtor a locking record, the locking record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request, to credit the transaction-related sub-register of the creditor by storing in the transaction-related sub-register of the creditor a credit record, the credit record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request, and to debit the transaction-related sub-register of the debtor by storing in the transaction- related sub-register of the debtor a debit record, the debit record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request.

In an embodiment, the processors are configured to compress the contents of a particular sub-register by calculating for the particular sub-register a current balance of the Underlying associated with the particular sub-register, using credit records, stored in the particular sub-register to record transactions with amounts of the respective Underlying credited to the holder of the sub-register, and debit records, stored in the particular sub register to record transactions with amounts of the respective Underlying debited from the holder of the sub-register; storing the current balance in the particular sub-register; and deleting the credit records and the debit records stored from the particular sub register. Consolidating the contents of sub-registers by calculating and storing in the respective sub-register an updated current balance of Underlying associated with the respective sub-register and deleting from the respective sub-register debit and credit records considered in the updated balance make it possible to compress the contents of the respective sub-register and reduce the number of records to be processed in validating transactions, which further expedites processing and reduces processing times.

In addition to the computer system for processing Underlying transactions, the present invention also relates to a computer-implemented method of processing Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlying. The method comprises a plurality of processors of a computer system executing the steps of: receiving from a plurality of external transaction entities a plurality of Underlying-related transaction requests via a communication network, each transaction request defining a specific amount of a particular Underlying to be transferred from an identified debtor to an identified creditor; processing received transaction requests; and respectively transmitting to the external transaction entities transaction confirmation messages via the communication network, upon completion of the processing of the received transaction requests. The method further comprises the processors executing the steps of: storing in a data storage system of the computer system a plurality of accounts and a plurality of sub-registers, each account storing for a particular holder the sub-registers associated with the particular holder, and each sub register being associated with one particular Underlying and storing for the particular holder the amount of the particular Underlying owned by the particular holder; and processing a received transaction request by applying a lock on the transaction-related sub-register of the debtor, associated with the holder identified as debtor in the received transaction request and associated with the particular Underlying defined in the received transaction request; subsequently to applying the lock, crediting the transaction-related sub-register of the creditor, associated with the holder identified as creditor in the received transaction request and associated with the particular Underlying defined in the received transaction request, with the amount of the particular Underlying defined in the received transaction request; subsequently to crediting the transaction-related sub register of the creditor, cancelling the lock applied on the transaction-related sub-register of the debtor, and debiting the transaction-related sub-register of the debtor with the amount of the particular Underlying defined in the received transaction request, for the completion of the processing of the received transaction request. In an embodiment, the method further comprises the processors applying the lock on the transaction-related sub-register of the debtor by blocking the amount of the particular Underlying defined in the received transaction request.

In an embodiment, the method further comprises the processors checking validity of the received transaction request, prior to crediting the transaction-related sub-register of the creditor, by determining for the transaction-related sub-register of the creditor a current balance of the particular Underlying defined in the received transaction request, whereby the amount of Underlying blocked in the transaction-related sub-register of the debtor is subtracted in the current balance, and not executing the received transaction request, if the current balance of the particular Underlying is below the amount of the particular Underlying defined in the received transaction request.

In an embodiment, the method further comprises the processors executing concurrently the processing of a plurality of the received transaction requests.

In an embodiment, the method further comprises the processors applying the lock on the transaction-related sub-register of the debtor by storing in the transaction-related sub- register of the debtor a locking record, the locking record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request, crediting the transaction-related sub-register of the creditor by storing in the transaction-related sub-register of the creditor a credit record, the credit record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request, and debiting the transaction-related sub-register of the debtor by storing in the transaction-related sub-register of the debtor a debit record, the debit record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request. In an embodiment, the method further comprises the processors compressing the contents of a particular sub-register by calculating for the particular sub-register a current balance of the Underlying associated with the particular sub-register, using credit records, stored in the particular sub-register to record transactions with amounts of the respective Underlying credited to the holder of the sub-register, and debit records, stored in the particular sub-register to record transactions with amounts of the respective Underlying debited from the holder of the sub-register; storing the current balance in the particular sub-register; and deleting the credit records and the debit records stored from the particular sub-register. In addition to the computer system and the computer-implemented method for processing Underlying transactions, the present invention also relates to a computer program product comprising a non-transitory computer-readable medium having stored thereon computer program code configured to control a plurality of processors of a computer system to process Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlying by executing the steps of: receiving from a plurality of external transaction entities a plurality of Underlying- related transaction requests via a communication network, each transaction request defining a specific amount of a particular Underlying to be transferred from an identified debtor to an identified creditor; processing received transaction requests; and respectively transmitting to the external transaction entities transaction confirmation messages via the communication network, upon completion of the processing of the received transaction requests. The computer program code is further configured to control the processors to execute the steps of: storing in a data storage system of the computer system a plurality of accounts and a plurality of sub-registers, each account storing for a particular holder the sub-registers associated with the particular holder, and each sub-register being associated with one particular Underlying and storing for the particular holder the amount of the particular Underlying owned by the particular holder; and processing a received transaction request by applying a lock on the transaction- related sub-register of the debtor, associated with the holder identified as debtor in the received transaction request and associated with the particular Underlying defined in the received transaction request; subsequently to applying the lock, crediting the transaction- related sub-register of the creditor, associated with the holder identified as creditor in the received transaction request and associated with the particular Underlying defined in the received transaction request, with the amount of the particular Underlying defined in the received transaction request; subsequently to crediting the transaction-related sub- register of the creditor, cancelling the lock applied on the transaction-related sub-register of the debtor, and debiting the transaction-related sub-register of the debtor with the amount of the particular Underlying defined in the received transaction request, for the completion of the processing of the received transaction request.

In an embodiment, the computer program code is further configured to control the processors to apply the lock on the transaction-related sub-register of the debtor by blocking the amount of the particular Underlying defined in the received transaction request.

In an embodiment, the computer program code is further configured to control the processors to check validity of the received transaction request, prior to crediting the transaction-related sub-register of the creditor, by determining for the transaction- related sub-register of the creditor a current balance of the particular Underlying defined in the received transaction request, whereby the amount of Underlying blocked in the transaction-related sub-register of the debtor is subtracted in the current balance, and not execute the received transaction request, if the current balance of the particular Underlying is below the amount of the particular Underlying defined in the received transaction request.

In an embodiment, the computer program code is further configured to control the processors to execute concurrently the processing of a plurality of the received transaction requests. In an embodiment, the computer program code is further configured to control the processors to apply a lock on the transaction-related sub-register of the debtor by storing in the transaction-related sub-register of the debtor a locking record, the locking record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request, to credit the transaction-related sub-register of the creditor by storing in the transaction-related sub register of the creditor a credit record, the credit record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request, and to debit the transaction-related sub- register of the debtor by storing in the transaction-related sub-register of the debtor a debit record, the debit record comprising a transaction identifier of the received transaction request and the amount of the particular Underlying defined in the received transaction request.

In an embodiment, the computer program code is further configured to compress the contents of a particular sub-register by calculating for the particular sub-register a current balance of the Underlying associated with the particular sub-register, using credit records, stored in the particular sub-register to record transactions with amounts of the respective Underlying credited to the holder of the sub-register, and debit records, stored in the particular sub-register to record transactions with amounts of the respective Underlying debited from the holder of the sub-register; storing the current balance in the particular sub-register; and deleting the credit records and the debit records stored from the particular sub-register.

Brief Description of the Drawings

The present invention will be explained in more detail, by way of example, with reference to the drawings in which: Figure 1 : shows a block diagram illustrating schematically a computer system according to the prior art for processing Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlyings. Figure 2: shows a block diagram illustrating schematically a computer system comprising a plurality of sub-registers used for processing Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlyings.

Figure 3: shows a block diagram illustrating schematically an exemplary configuration of accounts of holders and their associated sub-registers which are related to different Underlyings.

Figure 4: shows a block diagram illustrating schematically an exemplary configuration of a sub-register related to a particular Underlying configured to store credit, debit, and lock records related to the particular Underlying. Figure 5: shows a flow diagram illustrating an exemplary sequence of steps for processing Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlyings.

Figure 6: shows a table illustrating a generic example of a plurality of sub-registers of a plurality of holders for a particular Underlying. Figure 7: shows a table illustrating a specific example of a plurality of sub-registers of a plurality of holders for a particular Underlying. Detailed Description of the Preferred Embodiments

In Figures 1 and 2, reference numeral 2 refers to a plurality of external transaction entities, who use communication terminals, e.g. mobile devices, such as laptop computers or mobile phones, or stationary computers, comprising one or more processors, to submit transaction requests 22 related to a plurality of different Underlying via a communication network 20 to the computer system 1 , 3 for processing Underlying transactions. The computer supported external transaction entities 2 include financial investors, who submit transaction requests 22 directly, and centralizing entities, such as stock exchanges, financial institutions, or government agencies, etc., which receive and forward the transaction requests 22 to the computer system 1 , 3 for Underlying transaction processing.

The communication network 20 includes local area networks ( LAN ) , wireless local area networks (WLAN ), mobile radio networks, such as GSM (Global System for Mobile communication) or U MTS ( Universal Mobile Telephone System) or another mobile radio telephone system, fixed line communication links, and/or the Internet.

The computer systems 1 , 3 comprise electronic communication circuits 1 2 configured to exchange data with communication terminals of the external transaction entities 2 via communication network 20.

As illustrated schematically in Figures 1 and 2, the computer systems 1 , 3 comprise a plurality of processors 1 0, 30, and a data storage system 1 1 , 3 1 , connected respectively to the processors 1 0, 30. The processors 1 0, 30 are arranged in one or more operable computers. The computer system 1 further comprises a computer readable medium, e.g. memory and/or solid state drive(s) (SSD), having stored thereon computer program code configured to control the processors 1 0 such that they execute various functions and steps as described later in more detail with reference to Figure 5.

Unlike the prior art computer system 3 of Figure 1 , which comprises one common Register 32 implemented in the data storage system 31 for recording Underlying transactions, the computer system 1 of Figure 2 comprises a plurality of Sub-Registers SR (SR 1 , SR2, SRn) implemented in the data storage system 1 1 for storing in each case for a particular holder the amount of a particular Underlying owned by the particular holder. Specifically, the data storage system 1 1 is configured to store a plurality of accounts for holders and a plurality of sub-registers SR (SR 1 , SR2, SRn), whereby each sub-register SR (SR 1 , SR2, SRn) is associated with one holder and one Underlying. Accordingly, the processors 1 0 of the computer system 1 are configured to create, store, read, write, and delete the accounts AC and related sub-registers SR (SR 1 , SR2, SRn) in the data storage system 1 1 , as described below with reference to Figures 3 and 4.

As illustrated in more detail in the example of Figure 3, the (holder) accounts AC are stored in the data storage system 1 1 and are each associated with one specific holder H 1 , H2, Hz. The data structure of an account AC includes at least a data element with an identifier of a holder H (H 1 , H2, Hz). As illustrated schematically in Figure 3, each account AC of a holder H is linked to one or more sub-registers SR. Accordingly, the data structure of an account AC includes one or more data elements with one or more references, e.g. an identifier, pointer or link, to a sub-register SR associated with a particular Underlying associated with the respective account AC and its respective holder H ( H 1 , H2, Hz). Each sub-register SR is associated with one and only one Underlying, and each sub-register SR is associated with and linked to one and only one holder H (H I , H2, Hz). In the example of Figure 3, holder H 1 is associated with and linked to sub- register SR 1 A related to Underlying A, sub-register SR 1 B related to Underlying B, and sub-register SR 1 n related to Underlying n; holder H2 is associated with an linked to sub register SR2A related to Underlying A and sub-register SR2n related to Underlying n; holder Hz is associated with an linked to sub-register SRzA related to Underlying A, sub register SRzB related to Underlying B, and sub-register SRzn related to Underlying n. Figure 4 illustrates schematically the data structure of a sub-register SRn associated with a particular Underlying U. As illustrated in Figure 4, the sub-register SRn comprises credit records CR, debit records DR, and locking records LR. Each credit record CR indicates an executed credit transaction and comprises a transaction number t1 , t2, t3, t4 and a credit amount d , c2, c3, c4 indicative of the amount of respective Underlying U credited to the holder H of the sub-register SRn. Specifically, the credit amount d , c2, c3, c4 defines for the respective transaction t1 , t2, t3, t4, the amount of increase of Underlying, i.e. the increase of ownership rights, subsequent to the execution of the transaction t1 , t2, t3, t4. Each debit record DR indicates an executed debit transaction and comprises a transaction number t5, t6, t7, t8 and a debit amount d 1 , d2, d3, d4 indicative of the amount of respective Underlying U debited from the holder H of the sub-register SRn. Specifically, the debit amount d 1 , d2, d3, d4 defines for the respective transaction t5, t6, t7, t8, the amount of reduction of Underlying, i.e. the reduction of ownership rights, subsequent to the execution of the transaction t5, t6, t7, t8. Each locking record LR indicates a blocked (locked) amount of a pending Underlying transaction and comprises a transaction number t9, t1 0, t1 1 , t1 2 and a blocked amount L 1 , L2, L3, L4 indicative of the amount of respective Underlying U to be debited from the sub-register SRn by executing the respective transaction t9, t1 0, t1 1 , t1 2. A blocked amount of Underlying is unlocked, and thereby deleted as a locking record LR from the respective sub-register SRn, either when the respective transaction t9, t1 0, t1 1 , t1 2 is validated and executed by debiting the amount from the respective sub-register SRn, or when the respective transaction t9, t1 0, t1 1 , t1 2 is cancelled and the amount credited (back) to the respective sub-register SRn.

As illustrated in Figure 4, the data structure of a sub-register SRn further comprises data elements related to a rejuvenation balance RB and a rejuvenation date RD. The term "rejuvenation" relates to consolidating or compressing a sub-register SRn by calculating at a certain point in time, subsequently referred to and recorded as rejuvenation date RD, the current balance of Underlying of the respective sub-register SRn, taking into account a present rejuvenation balance RB of the respective sub-register SRn, calculated at the preceding, previous rejuvenation date RD, adding the credit amounts d , c2, c3, c4 of any credit record CR of the respective sub-register SRn, and subtracting the debit amounts d 1 , d2, d3, d4 of any debit record DR of the respective sub-register SRn; by storing this current balance of Underlying as the rejuvenation balance RB of the respective sub-register SRn; by storing the current date and time (e.g. YYYY-mm-dd- FIFI:MM:ss.SSS) as the respective rejuvenation date RD of the respective sub-register SRn; and by clearing the transaction history by deleting from the respective sub-register SRn the credit records CR and debit records DR included in calculating the rejuvenation balance RB. The "rejuvenation" or corresponding process of consolidating or compressing one or more of the sub-registers SR is performed by at least one of the processors 1 0 of the computer system 1 , for example periodically, according to a defined "rejuvenation" or consolidation schedule, or on as needed basis, e.g. when a certain storage space threshold is exceeded and/or when a threshold for processing time required for computing the sub-registers current balance is exceeded.

In the following paragraphs, described with reference to Figure 5 are possible sequences of steps performed by the processors 1 0 of the computer system 1 for processing Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlying.

In step SO, transaction requests 22 related to ownership change of Underlying, i.e. 'Underlying transaction requests' 22, are received at the computer system 1 , by at least one processor 1 0, from the external transaction entities 2 or their communication terminals, respectively, via communication network 20. The receiving processor 1 0 assigns to each received transaction request 22 a unique transaction identifier, e.g. a transaction number, and a transaction date indicative of the point in time when the respective transaction request was received. The 'Underlying transaction requests' 22 define transactions for change of ownership of a specified amount of units of a specified Underlying U from a first party, the debtor, to a second party, the creditor. Each Underlying transaction request 22 comprises a reference or identification of the Underlying U which is to be transferred; an indication of an amount of units of the respective Underlying U to be transferred with the transaction; an identification of the debtor, i.e. the source from whom the Underlying U are to be transferred; and an identification of the creditor, i.e. the destination to whom the Underlying U are to be transferred.

Subsequently, in blocks B 1 , B2, B3, the received transaction requests 22 are processed in parallel by one of the processors 1 0, as outlined below for block B 1 . Specifically, the transaction requests 22 received in step SO are assigned in each case to a different processor 1 0 which is available and ready for processing the respective transaction request 22 in the respective block B 1 , B2, B3. Although Figure 5 shows a limited number of parallel processing blocks B 1 , B2, B3, one skilled in the art will understand that the computer system 1 is scalable for massively parallel transaction processing and that depending on the number of processors 1 0 in the computer system 1 , in a practical implementation, there will actually be hundreds or thousands of parallel processing blocks B 1 , B2, B3 executed by a corresponding number of hundreds or thousands of processors 1 0 configured to process the received transaction requests 22 in near-real- time.

In step S1 , the processor 1 0 assigned to processing the Underlying transaction request 22 in block B 1 checks the validity of the Underlying transaction request 22. For that purpose, the assigned processor 1 0 determines the specific sub-register SR associated with the Underlying U indicated in the transaction request 22 and the holder identified as the debtor in the Underlying transaction request 22. Thus, in the example of Figure 3, the assigned processor 1 0 determines from the accounts AC the holder H (H 1 , H2, H3) identified as the debtor in the Underlying transaction request 22 and identifies the respective holder's sub-register SR which relates to the Underlying specified in the transaction request 22; e.g. if the debtor corresponds to holder Hz and the transaction request 22 relates to Underlying B, the processor 1 0 determines the sub-register SRzB as the source sub-register for the transaction.

In step S2, the assigned processor 1 0 determines the current balance of the source sub register SRzB for the transaction. The current balance of the source sub-register SRzB indicates the actual amount of units of the respective Underlying B owned by the debtor that is available for a transfer ownership. The current balance of a sub-register related to Underlying U is calculated from its rejuvenation balance RB by adding the credited amounts d , c2, c3, c4 indicated in the credit records CR (total C), subtracting the debited amounts d 1 , d2, d3, d4 indicated in the debit records DR (total D), and subtracting the locked amounts L1 , L2, L3, L4 indicated in the locking records (total L). The transaction or creation time of the credit records CR, the debit records DR, and the locking records LR is younger (more recent) than the rejuvenation date (time) RD of the rejuvenation balance RB.

In step S3, the assigned processor 1 0 checks whether the current balance of the source sub-register SRzB, i.e. the amount of units of the respective Underlying B currently owned by the debtor Hz, is sufficient (equal or greater than) the transaction amount specified to be transferred in the respective transaction request 22. If the current balance of the source sub-register SRzB is insufficient (lower than the transaction amount specified in the respective transaction request 22), the assigned processor 1 0 continues in step S1 1 by rejecting the transaction request 22. Otherwise, the assigned processor 1 0 continues in step S4.

In step S4, the assigned processor 1 0 checks whether the transaction date assigned to the respective transaction request 22 is newer (younger) than the rejuvenation date RD of the source sub-register SRzB. The transaction date is compared to the source sub register's rejuvenation date RD in order to prevent double spending in case of a processing error. If the transaction date is not newer than the rejuvenation date RD, the assigned processor 1 0 continues in step S1 1 by rejecting the transaction request 22. Otherwise, the assigned processor 1 0 continues in step S5.

In step S5, the assigned processor 1 0 blocks in the source sub-register SRzB the transaction amount of the Underlying to be transferred as specified in the respective transaction request 22. Specifically, the assigned processor creates in the source sub register SRzB a locking record LR which indicates the blocked (locked) amount and the transaction number associated with the Underlying transaction request 22. In optional step S6, the validity of the Underlying transaction request 22 is further checked in an external Blockchain or other external distributed ledger ( DL) system 21 , e.g. an Ethereum or Hyperledger platform. For that purpose, the assigned processor 1 0 submits the Underlying transaction request 22 to the external Blockchain or other DL system 21 , whereby the debtor and the creditor of the transaction are respectively mapped to assigned cryptographic (public/private) key pairs in the computer system 1 for identifying the debtor and creditor in the external Blockchain or other DL system 21 . Accordingly, the transaction request submitted to the external Blockchain or other DL system 21 is signed by the private key assigned to the debtor and defines the creditor by way of the public key assigned to the creditor. If the transaction is rejected by the external Blockchain or other DL system 21 , the assigned processor 1 0 unblocks the blocked transaction amount, by deleting in the source sub-register SRzB the locking record LR for the respective Underlying transaction request 22, and continues in step S1 1 by rejecting the transaction request 22. Otherwise, the transaction is executed and recorded in the external Blockchain or other DL system 21 and the assigned processor 1 0 continues in step S7.

It shall be pointed out here that processing of the steps S2, S3, S4 (S 1 ) and S5 is executed sequentially by one and the same assigned processor 1 0. Subsequently, the optional step S6 is delegated to the external Blockchain or other DL system 21 . In order to avoid idle time, the processor 1 0 assigned to executing the sequence of steps S2, S3, S4 (S 1 ) and S5 is freed up and assigned to processing other transaction requests 22 while the optional step S6 is executed by the external Blockchain or other DL system 21 . The subsequent steps S7, S8, S9 and S 1 0 may be assigned to different processors 1 0 for execution. In step S7, the assigned processor 1 0 credits the transaction amount to the debtor identified in the respective transaction request 22. Specifically, the assigned processor 1 0 determines the specific sub-register SR associated with the Underlying indicated in the transaction request 22 and the holder identified as the creditor in the Underlying transaction request 22. Thus, in the example of Figure 3, the assigned processor 1 0 determines from the accounts AC the holder H ( H 1 , H 2 , H3 ) identified as the creditor in the Underlying transaction request 22 and identifies the respective holder's sub-register SR which relates to the Underlying specified in the transaction request 22; e.g. if the creditor corresponds to holder F11 , the assigned processor 1 0 determines the sub-register SR 1 B as the destination sub-register for the Underlying B defined in the exemplary transaction request 22. The transaction amount is credited to the creditor by the assigned processor 1 0 creating and storing in the destination sub-register SR 1 B a credit record for the respective transaction amount of units of Underlying B.

In step S8, the assigned processor 1 0 unblocks in the source sub-register SRzB of the debtor the transaction amount of the Underlying B credited to the destination sub register SR1 B of the creditor. Unblocking is performed by the assigned processor 1 0 deleting in the source sub-register SRzB the locking record LR for the respective Underlying transaction request 22.

In step S9, the assigned processor 1 0 debits in the source sub-register SRzB of the debtor the transaction amount of the Underlying B credited to the destination sub-register SR 1 B of the creditor. Specifically, the assigned processor 1 0 creates and stores in the source sub-register SRzB a debit record for the respective transaction amount of Underlying B.

In step S1 0, the assigned processor 1 0 generates for the processed Underlying transaction request 22 a confirmation message indicating completion of the transaction. The completion confirmation message is transmitted by the computer system 1 via the communication network 20 to the external transaction entity 2 or its communication terminal, respectively, which submitted the Underlying transaction request 22.

Figures 6 and 7 show tables illustrating examples of Underlyings based on and backed by shares and stock futures. While the example of Figure 6 is more generic, it relates to generic corporations "A" and "B", generic stock exchange "A", generic markets, generic ISINs (International Securities Identification Number), and generic symbols; the example of Figure 7 is more specific, it relates to specific companies "Orange" and "Engie", stock exchange "Euronext Paris", markets "XPAR" and "DPAR", specific ISINs and symbols "ORA", "ENGI" and "GA6". The middle section of the tables of Figures 6 and 7 illustrate the account management, specifically, the accounts AC of holders "1 ", "2", ..., "n" and their sub-registers for the different Underlyings. While Figure 6 indicates generic references to the Sub-registers, e.g. "Bundle 1 ABC" or "Bundle nABC", Figure 7 indicates specific amounts of units of Underlying owned by the respective holders, e.g. holder "3" owns 2031 59444 units of Underlying "ENGIE".

It should be noted that, in the description, the computer program code has been associated with specific functional modules and the sequence of the steps has been presented in a specific order, one skilled in the art will understand, however, that the computer program code may be structured differently and that the order of at least some of the steps could be altered, without deviating from the scope of the invention as claimed.

Claims

1 . A computer system ( 1 ) for processing Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlying, the computer system ( 1 ) comprising a communication circuit ( 1 2) configured to exchange data with a plurality of external transaction entities ( 2) via a communication network ( 20), a data storage system ( 1 1 ), and a plurality of processors ( 1 0) connected to the communication circuit and the data storage system ( 1 1 ) and configured to execute the steps of: receiving (SO) from the external transaction entities ( 2) a plurality of Underlying- related transaction requests (22) via the communication network (20), each transaction request (22) defining a specific amount of a particular Underlying to be transferred from an identified debtor to an identified creditor; processing ( B 1 , B2, B3) received transaction requests (22 ); and respectively transmitting to the external transaction entities (2 ) transaction confirmation messages via the communication network (20), upon completion of the processing of the received transaction requests (22); wherein the processors ( 1 0) are configured to execute the steps of: storing in the data storage system ( 1 1 ) a plurality of accounts (AC) and a plurality of sub-registers (SR), each account storing (AC) for a particular holder ( H 1 , H2,

H3) the sub-registers (SR 1 A, SR 1 B, SR 1 n, SR2A, SR2n, SRzA, SRzB, SRzn) associated with the particular holder (H 1 , H2, H3), and each sub-register (SRn) being associated with one particular Underlying (U ) and storing for the particular holder ( H 1 , H2, H3 ) the amount of the particular Underlying (U ) owned by the particular holder ( H 1 , H2, H3); and processing (B 1 ) a received transaction request (22 ) by applying a lock (S5 ) on the transaction-related sub-register (SRn) of the debtor, associated with the holder identified as debtor in the received transaction request (22 ) and associated with the particular Underlying defined in the received transaction request (22); subsequently to applying the lock, crediting (S7) the transaction-related sub register (SRn) of the creditor, associated with the holder identified as creditor in the received transaction request (22) and associated with the particular Underlying defined in the received transaction request (22 ), with the amount of the particular Underlying defined in the received transaction request (22); subsequently to crediting the transaction-related sub-register (SRn) of the creditor, cancelling (S8) the lock applied on the transaction-related sub-register (SRn) of the debtor, and debiting (S9) the transaction-related sub-register (SRn) of the debtor with the amount of the particular Underlying defined in the received transaction request (22 ), for the completion of the processing of the received transaction request (22). 2. The computer system ( 1 ) of claim 1 , wherein the processors ( 1 0) are configured to apply (S5) the lock on the transaction-related sub-register (SRn) of the debtor by blocking the amount of the particular Underlying defined in the received transaction request (22 ).

3. The computer system ( 1 ) of claim 2, wherein the processors ( 1 0) are configured to check validity ( S 1 ) of the received transaction request (22 ), prior to crediting the transaction-related sub-register (SRn) of the creditor, by determining (S2) for the transaction-related sub-register (SRn) of the creditor a current balance of the particular Underlying defined in the received transaction request ( 22 ), whereby the amount of Underlying blocked in the transaction-related sub-register (SRn) of the debtor is subtracted in the current balance, and not executing the received transaction request ( 22), if the current balance of the particular Underlying is below the amount of the particular Underlying defined in the received transaction request (22 ).

4. The computer system ( 1 ) of one of claims 1 to 3, wherein the processors ( 1 0) are configured to execute concurrently the processing ( B 1 , B2, B3) of a plurality of the received transaction requests (22).

5. The computer system ( 1 ) of one of claims 1 to 4, wherein the processors ( 1 0) are configured to apply (S 5 ) the lock on the transaction-related sub-register (SRn) of the debtor by storing in the transaction-related sub-register (SRn) of the debtor a locking record (LR), the locking record ( LR) comprising a transaction identifier (t9, tI O, tl 1 , t1 2) of the received transaction request (22) and the amount ( L 1 , L2, L3, L4) of the particular Underlying defined in the received transaction request (22 ), to credit (S7) the transaction-related sub-register (SRn) of the creditor by storing in the transaction-related sub-register (SRn) of the creditor a credit record (CR), the credit record (CR) comprising a transaction identifier (t1 , t2, t3, t4) of the received transaction request ( 22 ) and the amount (d , c2, c3, c4) of the particular Underlying defined in the received transaction request ( 22 ), and to debit (S9) the transaction-related sub-register (SRn) of the debtor by storing in the transaction-related sub-register (SRn) of the debtor a debit record (DR), the debit record (DR) comprising a transaction identifier (t5, t6, t7, t8) of the received transaction request ( 22 ) and the amount (d 1 , d2, d3, d4) of the particular Underlying defined in the received transaction request ( 22 ).

6. The computer system ( 1 ) of one of claims 1 to 5, wherein the processors ( 1 0) are configured to compress the contents of a particular sub-register (SRn) by calculating for the particular sub-register (SRn) a current balance of the Underlying associated with the particular sub-register (SRn), using credit records (CR), stored in the particular sub-register (SRn) to record transactions with amounts (d , c2, c3, c4) of the respective Underlying credited to the holder of the sub-register, and debit records (DR), stored in the particular sub-register (SRn) to record transactions with amounts (d 1 , d2, d3, d4) of the respective Underlying debited from the holder of the sub-register; storing the current balance in the particular sub-register (SRn); and deleting the credit records (CR) and the debit records (DR) from the particular sub-register (SRn). A computer-implemented method of processing Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlying, the method comprising a plurality of processors ( 1 0) of a computer system ( 1 ) executing the steps of: receiving (SO) from a plurality of external transaction entities (2) a plurality of Underlying-related transaction requests (22) via a communication network (20), each transaction request (22) defining a specific amount of a particular Underlying to be transferred from an identified debtor to an identified creditor; processing ( B 1 , B2, B3 ) received transaction requests ( 22 ); and respectively transmitting to the external transaction entities (2 ) transaction confirmation messages via the communication network (20), upon completion of the processing of the received transaction requests (22); wherein the method further comprises the processors ( 1 0) executing the steps of: storing in a data storage system ( 1 1 ) of the computer system ( 1 ) a plurality of accounts (AC) and a plurality of sub-registers (SR), each account (AC) storing for a particular holder (H I , H2, H3) the sub-registers (SR 1 A, SR 1 B, SR 1 n, SR2A, SR2n, SRzA, SRzB, SRzn) associated with the particular holder (H 1 , H2, H3 ), and each sub-register (SRn) being associated with one particular Underlying (U ) and storing for the particular holder ( H 1 , H2, H3 ) the amount of the particular Underlying (U ) owned by the particular holder (H I , H2, H3); and processing (B 1 ) a received transaction request (22 ) by applying a lock (S5 ) on the transaction-related sub-register (SRn) of the debtor, associated with the holder identified as debtor in the received transaction request (22 ) and associated with the particular Underlying defined in the received transaction request (22); subsequently to applying the lock, crediting (S7) the transaction-related sub register (SRn) of the creditor, associated with the holder identified as creditor in the received transaction request (22) and associated with the particular Underlying defined in the received transaction request (22 ), with the amount of the particular

Underlying defined in the received transaction request (22); subsequently to crediting the transaction-related sub-register (SRn) of the creditor, cancelling (S8) the lock applied on the transaction-related sub-register (SRn) of the debtor, and debiting (S9) the transaction-related sub-register (SRn) of the debtor with the amount of the particular Underlying defined in the received transaction request

(22 ), for the completion of the processing of the received transaction request (22).

8. The method of claim 7, further comprising the processors ( 1 0) applying the lock (S5 ) on the transaction-related sub-register (SRn) of the debtor by blocking the amount of the particular Underlying defined in the received transaction request (22 ). 9. The method of claim 8, further comprising the processors ( 1 0) checking validity (S1 ) of the received transaction request (22 ), prior to crediting the transaction- related sub-register (SRn) of the creditor, by determining (S2 ) for the transaction- related sub-register (SRn) of the creditor a current balance of the particular Underlying defined in the received transaction request ( 22 ), whereby the amount of Underlying blocked in the transaction-related sub-register (SRn) of the debtor is subtracted in the current balance, and not executing the received transaction request ( 22 ), if the current balance of the particular Underlying is below the amount of the particular Underlying defined in the received transaction request (22 ).

1 0. The method of one of claims 7 to 9, further comprising the processors ( 1 0) executing concurrently the processing (B 1 , B2, B3 ) of a plurality of the received transaction requests (22).

1 1 . The method of one of claims 7 to 1 0, further comprising the processors ( 1 0) applying the lock (S5 ) on the transaction-related sub-register (SRn) of the debtor by storing in the transaction-related sub-register (SRn) of the debtor a locking record (LR), the locking record (LR) comprising a transaction identifier (t9, t1 0, t1 1 , t1 2 ) of the received transaction request (22) and the amount ( L 1 , L2, L3, L4) of the particular Underlying defined in the received transaction request (22), crediting (S7) the transaction-related sub-register (SRn) of the creditor by storing in the transaction-related sub-register (SRn) of the creditor a credit record (CR), the credit record (CR) comprising a transaction identifier (t1 , t2, t3, t4) of the received transaction request (22) and the amount (d , c2, c3, c4) of the particular Underlying defined in the received transaction request (22), and debiting (S9) the transaction-related sub-register (SRn) of the debtor by storing in the transaction- related sub-register (SRn) of the debtor a debit record (DR), the debit record (DR) comprising a transaction identifier (t5, t6, t7, t8) of the received transaction request (22 ) and the amount (d 1 , d2, d3, d4) of the particular Underlying defined in the received transaction request ( 22 ). 1 2. The method of one of claims 7 to 1 1 , further comprising the processors ( 1 0) compressing the contents of a particular sub-register (SRn) by calculating for the particular sub-register (SRn) a current balance of the Underlying associated with the particular sub-register (SRn), using credit records (CR), stored in the particular sub-register (SRn) to record transactions with amounts (d , c2, c3, c4) of the respective Underlying credited to the holder of the sub-register, and debit records

(DR), stored in the particular sub-register (SRn) to record transactions with amounts (d 1 , d2, d3, d4) of the respective Underlying debited from the holder of the sub-register; storing the current balance (RB) in the particular sub-register (SRn); and deleting the credit records (CR) and the debit records ( DR) from the particular sub-register (SRn).

1 3. A computer program product comprising a non-transitory computer-readable medium having stored thereon computer program code configured to control a plurality of processors ( 1 0) of a computer system ( 1 ) to process Underlying transactions between a plurality of debtors and a plurality of creditors related to a plurality of different Underlying by executing the steps of: receiving (SO) from a plurality of external transaction entities (2) a plurality of Underlying-related transaction requests (22) via a communication network (20), each transaction request (22) defining a specific amount of a particular Underlying to be transferred from an identified debtor to an identified creditor; processing ( B 1 , B2, B3 ) received transaction requests ( 22 ); and respectively transmitting to the external transaction entities (2 ) transaction confirmation messages via the communication network (20), upon completion of the processing of the received transaction requests (22); wherein the computer program code is further configured to control the processors

( 1 0) to execute the steps of: storing in a data storage system ( 1 1 ) of the computer system ( 1 ) a plurality of accounts (AC) and a plurality of sub-registers (SR), each account (AC) storing for a particular holder (H I , H2, H3) the sub-registers (SR 1 A, SR 1 B, SR 1 n, SR2A, SR2n, SRzA, SRzB, SRzn) associated with the particular holder (H 1 , H2, H3 ), and each sub-register (SRn) being associated with one particular Underlying (U ) and storing for the particular holder ( H 1 , H2, H3 ) the amount of the particular Underlying (U ) owned by the particular holder (H I , H2, H3); and processing (B 1 ) a received transaction request (22 ) by applying a lock (S5 ) on the transaction-related sub-register (SRn) of the debtor, associated with the holder identified as debtor in the received transaction request (22 ) and associated with the particular Underlying defined in the received transaction request (22); subsequently to applying the lock, crediting (S7) the transaction-related sub register (SRn) of the creditor, associated with the holder identified as creditor in the received transaction request (22) and associated with the particular Underlying defined in the received transaction request (22 ), with the amount of the particular Underlying defined in the received transaction request (22); subsequently to crediting the transaction-related sub-register (SRn) of the creditor, cancelling (S8) the lock applied on the transaction-related sub-register (SRn) of the debtor, and debiting the transaction-related sub-register (SRn) of the debtor with the amount of the particular Underlying defined in the received transaction request (22), for the completion of the processing of the received transaction request (22).

1 4. The computer program product of claim 1 3, wherein the computer program code is further configured to control the processors ( 1 0) to apply the lock (S5 ) on the transaction-related sub-register (SRn) of the debtor by blocking the amount of the particular Underlying defined in the received transaction request (22 ).

1 5. The computer program product of claim 1 4, wherein the computer program code is further configured to control the processors ( 1 0) to check validity (S1 ) of the received transaction request ( 22 ), prior to crediting the transaction-related sub register (SRn) of the creditor, by determining (S2 ) for the transaction-related sub register (SRn) of the creditor a current balance of the particular Underlying defined in the received transaction request (22 ), whereby the amount of Underlying blocked in the transaction-related sub-register (SRn) of the debtor is subtracted in the current balance, and not execute the received transaction request (22), if the current balance of the particular Underlying is below the amount of the particular Underlying defined in the received transaction request ( 22 ).

1 6. The computer program product of claims 1 3 to 1 5, wherein the computer program code is further configured to control the processors ( 1 0) to execute concurrently the processing (B 1 , B2, B3 ) of a plurality of the received transaction requests (22).

1 7. The computer program product of one of claims 1 3 to 1 6, wherein the computer program code is further configured to control the processors ( 1 0) to apply a lock (S5 ) on the transaction-related sub-register (SRn) of the debtor by storing in the transaction-related sub-register (SRn) of the debtor a locking record ( LR), the locking record (LR) comprising a transaction identifier (t9, t1 0, t1 1 , 11 2 ) of the received transaction request ( 22 ) and the amount (L1 , L2, L3, L4) of the particular Underlying defined in the received transaction request (22), to credit the transaction-related sub-register (SRn) of the creditor by storing in the transaction- related sub-register (SRn) of the creditor a credit record (CR), the credit record (CR) comprising a transaction identifier (t 1 , t2, t3, t4) of the received transaction request (22) and the amount (d , c2, c3, c4) of the particular Underlying defined in the received transaction request (22), and to debit the transaction-related sub- register (SRn) of the debtor by storing in the transaction-related sub-register (SRn) of the debtor a debit record (DR), the debit record (DR) comprising a transaction identifier (t5, t6, t7, t8) of the received transaction request ( 22 ) and the amount (d 1 , d2, d3, d4) of the particular Underlying defined in the received transaction request (22 ). 1 8. The computer program product of one of claims 1 3 to 1 7, wherein the computer program code is further configured to control the processors ( 1 0) to compress the contents of a particular sub-register (SRn) by calculating for the particular sub register (SRn) a current balance of the Underlying associated with the particular sub-register (SRn), using credit records (CR), stored in the particular sub-register (SRn) to record transactions with amounts (d , c2, c3, c4) of the respective

Underlying credited to the holder of the sub-register, and debit records ( DR), stored in the particular sub-register (SRn) to record transactions with amounts (d 1 , d2, d3, d4) of the respective Underlying debited from the holder of the sub register; storing the current balance ( RB) in the particular sub-register (SRn); and deleting the credit records (CR) and the debit records (DR) from the particular sub register (SRn).