WO2019220251A1 - Automatic inter-bank reconciliation system - Google Patents

Automatic inter-bank reconciliation system Download PDF

Info

Publication number
WO2019220251A1
WO2019220251A1 PCT/IB2019/053632 IB2019053632W WO2019220251A1 WO 2019220251 A1 WO2019220251 A1 WO 2019220251A1 IB 2019053632 W IB2019053632 W IB 2019053632W WO 2019220251 A1 WO2019220251 A1 WO 2019220251A1
Authority
WO
WIPO (PCT)
Prior art keywords
rules
transactions
shared
nodes
ledger
Prior art date
Application number
PCT/IB2019/053632
Other languages
French (fr)
Inventor
Romano Stasi
Silvia ATTANASIO
Giulio MURRI
Original Assignee
Abi Lab - Centro Di Ricerca E Innovazione Per La Banca
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Abi Lab - Centro Di Ricerca E Innovazione Per La Banca filed Critical Abi Lab - Centro Di Ricerca E Innovazione Per La Banca
Priority to EP19729822.7A priority Critical patent/EP3794543A1/en
Publication of WO2019220251A1 publication Critical patent/WO2019220251A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1474Saving, restoring, recovering or retrying in transactions

Definitions

  • the present invention regards the field of reconciliation of inter-bank relationships.
  • the proposed invention regards a method and a system for the automatic reconciliation of mutual accounts and pending items based on a distributed digital platform and a dynamic set of shared rules for the management, investigation and resolution of unchecked transactions.
  • a first problem lies in the process times: the times required to reconcile the inter-bank relationships are quite long, typically monthly due to the due to the extension of a consolidated and established practice relating to the reaching of a widespread consensus by the banks over time.
  • a further problem regards the transparency of the reconciliation operations in the current configuration.
  • the method that is conventionally used for the reconciliation of mutual accounts provides for the periodic election of the owner of the reconciliation, whom is thus given the full responsibility of matching the transactions.
  • the owner becomes the sole player with full access to the operations carried out, to the detriment of the counterparty who only plays a support role.
  • the owner bank of the reconciliation will only use the systems thereof and the internal procedures which are not only different from those of the counterparty, but they are physically separated and inaccessible: this represents a clear problem in terms of communication and movement of information flow, to a point of leading, in some cases, a bank to losing visibility of its property.
  • alternating nature of the owner of the reconciliation requires the need to invert the process periodically.
  • a method and system for the automatic reconciliation of inter-bank reports which effectively solves the aforementioned problems is provided.
  • the proposed solution is based on a distributed digital infrastructure which interconnects the computer nodes of the banking institutes in question and which provides a reconciliation process in an automatic fashion using:
  • the system may advantageously involve a predetermined number of players, with a minimum number of two and a maximum solely limited to the available technology and tendentially scalable at will.
  • players will be used to indicate any Entity or institution that needs to hold inter-bank relationships, this category thus including: banks and banking institutes, credit institutes, bank groups, financial organisations and the like.
  • the digital infrastructure will support a system of the of the distributed type and it will be obtained by providing each player with at least one processing node with characteristics suitable to appropriately process the input and output data flows.
  • each processing node will be provided with the following minimum requirements:
  • one or more central processing units with possibility of parallel calculation and capacity of direct access to the memory
  • a random-access central memory co-located with respect to the processing unit and with dimensions sufficient to contain the programme data and workflows;
  • peripherals for interconnection and interfacing to the local network and to the external network included in the data switching and routing hardware
  • NAS high-speed mass storage areas
  • SAN high-speed mass storage areas
  • control terminals local or remote.
  • each processing node will be set up in the high reliability fail-safe configuration, both in terms of processing system and in terms of storage.
  • Each node will be suitably completed with one or more back-up systems obtained in any manner suitable to allow the full restoration of efficiency following a damaging event.
  • the processing nodes network may be advantageously obtained according to any interconnection and communication protocol, including proprietary protocols specifically developed for the system in question.
  • the processing network will be developed vertically in compliance with the most common standards, such as for example the OSI model, with the aim of allowing greater compatibility and interoperability and for facilitating input into the node network and pre-existing infrastructures.
  • Data traffic will advantageously be subjected to ciphering and the access, both physical and application, to the communication network will be rigidly subjected to a system of permissions and privileges.
  • the processing nodes of each player will be provided with control peripherals, data inspection and filtering (firewall, packet analyser, network traffic monitor).
  • each single processing node will be provided with the required basic software (operating systems, drivers, programme interfaces, virtualisation systems, ...) and with the application software that obtains the method described hereinafter.
  • Said application software will be suitably provided with man-machine graphic interfaces (GUI).
  • GUI man-machine graphic interfaces
  • the application software can be implemented additionally and alongside the applications already used in the field of accounting/management, guaranteeing the interoperability thereof. In the cases requiring it, the software will see to executing the interface for translating and converting the input and output messages from the accounting systems already in use, with the aim of achieving full compatibility with the communication protocols of the system subject of the invention.
  • the core of the offered solution lies in a method that implements a shared ledger, a set of common rules and a mechanism for incorporating the specific rules.
  • a shared ledger is indispensable for tracing the transactions on mutual accounts, simultaneously guaranteeing the visibility of the entries to both parties. He sharing of the ledger advantageously allows overcoming the limitations entailed by the owner-based paradigm of the ledger and regarding the periodic inversion of the reconciliation, enhancing the strong points at the same time.
  • each player records the transactions thereof and has access to the entries carried out by the counterparty. It is thus possible to view the transactions without having to wait for the transfer of flows from the counterparty.
  • the ledger may also be provided with autonomous capacity to process small code parts or a predefined set of instructions which act on the information contained therein without external supervision. Such capacity will for example be used to reduce, eliminate or automatically tore the items regarding transactions that already match according to the shared rules.
  • the ledger may conveniently be created through the possible implementations that can be obtained according to contemporary technique and practices.
  • Such implementations include, but are not limited to: - Distributed filesystems;
  • DDBMS Distributed DataBase Management System
  • DLT Distributed Ledger Technology
  • the shared register must always allow the players with inter-bank relationships full accessibility to the entries regarding the transactions thereof, simultaneously guaranteeing that no one else can obtain such access in any manner whatsoever without authorisation.
  • third parties may possibly be involved solely as replication or redundancy nodes.
  • a possible embodiment of the shared ledger may for example provide for each node of the system to:
  • the part of the ledger not regarding one’s transactions stored by a node may be determined based on observations on redundancy and restoration of data integrity following the failure of one or more nodes (fault tolerance).
  • the system will define a set of rules (ruleset) for matching the transactions on accounts regarding inter-bank relationships.
  • the rules will be set based on parameters of computational efficiency, economicity of network traffic, replicability and reliability of the information contained therein and they will be natively and imperatively implemented on all network processing nodes.
  • the aspects defined by the ruleset, regarding the reconciliation process comprise, but are not limited to: message and data flow format (record length, number and type of fields in the record, presence of checksum, etc.);
  • matching parameters (amounts, value dates, marks, direction of the transactions etc.);
  • the system will advantageously allow the division of the ruleset into two categories of rules:
  • specific supplementary rules they are applied to a single, specific mutual account in the bank system and they are solely implemented on the nodes and in the items of the ledger involved.
  • the specific rules may regard any aspect of the relationship, ranging from the data flow format to the pending items investigation procedures.
  • the pool of the defined shared rules simultaneously represents the crucial requirement for accessing the system and the pre-set level of ambition.
  • each player who enters, at any level, into the automatic reconciliation system must adopt the shared set of rules.
  • Such rules may be subsequently supplemented with possible specific additional information.
  • the system provides for that the specific rules be progressively incorporated and supplemented in the shared rules through a polling process and periodic consent set as below:
  • each player/node will express a binding preference to upgrade a rule from specific to global;
  • defined may be a number of specific rules which, at each polling cycle, must be compulsorily be eliminated for assimilation in shared common rules, with the set aim of eliminating any off-standard procedure.
  • the interval between polling cycles the type and number of consensus will depend on the particular embodiment based on the contingent needs.
  • a possible implementation could for example require to incorporate 10% of the specific rules in the shared rules every two years and that the upgrade of a specific rules will require a simple majority consensus.
  • the system may advantageously be provided with a subsystem for monitoring and tracing the use and the statistical occurrence of each specific rule, providing suggestions on the suitability of upholding it or not with the possibility of generating impact prediction scenarios.
  • the matching and investigation rules may be directly entered as an element or item of the shared ledger in form of instructions and lines of code to be carried out on the processing nodes.
  • a further possibility may be the implementation of rules in the shared ledger like a smart contract.
  • the system will be capable of automatically, and potentially in real time, carrying out the reconciliation process verifying the transactions, checking the status of the creditor and debtor, automatically reconciling the transactions and processing the pending items.
  • the same rules will advantageously allow to separate the physiological pending items and the pending items subject of investigation and which require involving the counterparty.
  • it will be possible to decline an investigation procedure that exploits the potential of the network and the sharing of the transactions ledger so as to automate the flow processes regarding the transfer and breakdown of the operations, including those already reconciled, marginalising manual operations and limiting them to the most critical pending items and manual matching.
  • the proposed method will allow to reduce human intervention to the minimum and considerably increase the efficiency of the process.
  • the system may implement machine learning algorithms for tracing the manual activity of the operators and process suggestions to be subjected to the attention of the head of process with the aim of implementing new automatic rules.
  • the automatic reconciliation system provided for, in the most complete embodiment, a support system that allows to use the resources of the processing network for:
  • MFA Multi-Factor Authentication
  • FIGURE 1 shows the representation of some possible transactions recorded on mutual accounts 520 and which require the reconciliation process 521 : shares 510, cheques 511, bank transfers 512 and accounts 513. The transfer of a transaction 525 in proprietary format on an accounting computer system 530 is illustrated.
  • FIGURE 2 shows a possible embodiment of a general processing node 150 of the automatic reconciliation system, consisting of a central processor 151 provided with storage 153, accessory servers 152, access terminals 154 and ethernet connection 155 to the IP network 600 through firewall 156.
  • the same figure also illustrates two possible configurations of the processing nodes network in which seven nodes, named 1501..1507, are connected to a star-like network 610 or in a peer to peer network 620.
  • FIGURE 3 shows a possible logical implementation of the shared ledger 120 in a four- player system. Numbered are two banks 1501 and 1502 and the ledger portions written or stored by each: a mutual item 121, an exclusive relevance record 122 and an atomic fragment of the ledger 123.
  • FIGURE 4 shows the process for polling and incorporating the rules 300. Numbered are various cycle steps for supplying the shared rules 310 which starts with the creation of specific rules 311 and, after a waiting period 312, it is subjected to a polling 313. The determination of the consensus 314 and the possible alternatives consisting in acceptation 316 or rejection 315.
  • FIGURE 5 shows the flow chart of the automatic reconciliation process 200.
  • the various process steps are illustrated and divided among the various peer nodes 1501 and 1502 and which share the digital ledger 125. The following are numbered: entering transactions 201, processing matching 202, identifying pending items 204, preliminary verification 203, internal investigation process 205 regarding shared records 207 assisted by automatically generated suggestions 206, possible manual correction 208 and entering reconciled transactions 209.
  • One of the nodes has a mechanism for automatically generating suggestions 210 for the operator during reconciliation.
  • a banking institute holding relationships 520 with one or more counterparties is taken for example.
  • transactions of various origin and nature such as: shares 510, cheques 511, bank transfers 512 and accounts 513.
  • Each generated transaction is transferred to the accounting system 530 of the bank through a formatted message 525.
  • the mutual nature of the accounts gives rise to the need of performing a reconciliation process 512 on the same so as to identify and reconcile mismatches, if present.
  • the automatic reconciliation system in the distributed embodiment subject of the invention, includes all three key elements of the model:
  • the system is scalable and extendable to an indefinite number of players/nodes.
  • processing node 150 which, with reference to FIG. 2, consists of a complex hardware/software and consisting of:
  • a central system 151 which provides the main processing capacity of the node
  • slaved servers 152 which have the secondary functions of web server, proxy, directory server for the authentication of users and services, etc.; a high capacity and high-performance storage sub-system 153, with direct access to the communication network (SAN);
  • the infrastructure will have access to the IP network 600 through channels that are secure, redundant and provided with an appropriate quality of service.
  • the embodiment of the example will be provided with an operating system capable of managing true multitasking processes, parallel calculation, simultaneous access of several appliances and the concurrent and parallel use of hardware resources.
  • the application software is specifically developed for obtaining the functionalities of the method described in detail hereinafter with reference to a flow chart in FIG. 5.
  • the processing nodes are shown in the figure with progressive numbers 1501 to 1507, for a system comprising seven players for the sake of brevity.
  • Any type of network can be implemented: in the embodiment, the type is of the peer to peer 620 type with redundant connections and some centralised services.
  • the method is based on sharing information regarding transactions on accounts regarding inter-bank relationships and it provides for that the processing nodes have access to such information by implementing a shared ledger which, though maintaining the reconciliation owner concept, reduces the disadvantages thereof, in particular eliminating process asymmetries.
  • the shared ledger 120 is implemented by means of a distributed database (DDBMS) with block redundancy and distributed peer control.
  • DDBMS distributed database
  • the ledger is divided into elementary storage blocks 123 which are hierarchically aggregated in exclusive relevance records 122 which in turn form the items 121 of the ledger.
  • Each item 121 contains one or more transactions regarding the same node and it thus consists of an exclusive relevance record of the first node and an exclusive relevance record of the second node, thus fully reflecting the symmetry of the transactions on the account.
  • the illustration of FIG. 2 shows two nodes, named node“A” 1501 and node“B” 1502 which concurrently make entries in a ledger which contains the transactions of other nodes of the network.
  • Each node locally contains a copy and full access to all items 121 containing records of their own relevance 122: hence, the nodes have immediate access to the transactions of the counterparty in the systems thereof.
  • each node takes part in the fault tolerance strategy of the system by storing a copy of some selected elementary storage blocks 123 regarding the items of the other players, called external blocks. Contrary to the exclusive relevance records, such blocks cannot be accessed in reading, but remain available in the network in case of restoration.
  • the number of nodes in the system taken for example, and the distribution strategy of the external blocks allow achieving tolerance to the loss of data of two nodes without affecting the system (full reconstruction of the ledger).
  • the node“A” 1501 locally has items“A-B”,“A-C” and“A-D” and it may preserve some blocks 123 of items“B-C”,“B-D” and“C-D”, but without the possibility of reconstructing the information contained therein.
  • the system provides for defining a set of shared rules (ruleset) for matching the transactions.
  • the ruleset is optionally extendable by each counterparty with the addition of specific rules.
  • the shared rules regard the following aspects:
  • JSON format for messages and records, length and number of fixed fields, aligned fields
  • classification of pending items based on: amount, value date, mark.
  • Acceptation and implementation of the previous rules will be a compulsory requirement for access to the network by any new players. It will be possible to enter additional rules and unlimited validity to a pool of nodes (for example further specifications for classifying pending items) of said specific rules.
  • the preferred embodiment allows entering specific rules directly on the shared ledger in form of smart contracts.
  • the model provides for that the specific rules be progressively thinned out and incorporated according to the polling process 300 illustrated in FIG. 3.
  • the system is based on a shared set of rules 310 to which a given number of specific rules 311 are added for each inter-bank relationship
  • the interval will be a shared rule, there will be carried out the interview and polling sub-process 313 to maintain or eliminate the status of specific rule.
  • the result of the polling 314 will determine which rules will be accepted and converted 316 falling within the pool of shared rules and which will be rejected 315, remain specific.
  • the process parameters are defined, considering the same interval as the polling cycle, in the shared rules.
  • the system automatically processes the transactions as soon as available, cross checking the mutual ledger items 202;
  • the ledger signals them 204 to the counterparties, otherwise the process ends with the final entry of the transactions 209; each counterparty, as regards the relevant items thereof, checks the unreconciled items and decides on whether to carry out an investigation 205 or close the process;
  • the investigation 205 may be supported by suggestions 206 generated by the system and considers all records contained in the ledger 207 without requiring to transfer flows from one node to the other;
  • each player has the prerogative to supplement the data stored in the shared ledger with archived evidence 211;
  • the process ends with the entry of the reconciled transactions and the system returns to the initial status.

Abstract

Method and system for the automatic reconciliation of inter-bank relationships, characterised in that it is based on a distributed digital platform consisting of a network (620) of processing nodes (150) of banking institutes; said processing nodes having services suitable for processing the input and output flows; said processing nodes (150) being provided with software that implements the automatic reconciliation process thanks to three key elements: (A) a shared ledger (120) for the transactions on inter-bank relationships (520) which allows the verification and reconciliation of accounts; said ledger being implemented according to any technical solution on distributed architecture; said ledger (120) allowing full access to the items (121) regarding the transactions thereof; said ledgers having independent processing capacities; (B) a dynamic set of rules natively implemented in the system; said rules being divided into rules common to all nodes (310) and specific rules (311); said rules being suitable to be inserted into the shared ledger in of instruction records with the aim of allowing the automatic matching of the transactions in real time; (C) a cyclic process (300) for streamlining and progressively optimising the specific rules (311) in the pool of shared rules (310) by means of a polling mechanism with consent.

Description

“Automatic inter-bank reconciliation system”
Description Field of the art
The present invention regards the field of reconciliation of inter-bank relationships. In particular, the proposed invention regards a method and a system for the automatic reconciliation of mutual accounts and pending items based on a distributed digital platform and a dynamic set of shared rules for the management, investigation and resolution of unchecked transactions.
Prior art
At the state of the art there are numerous inter-bank relationships reconciliation and reconciliation systems. Such process, which consists in the reconciliation of the transactions that generate entries on mutual accounts and in the management of pending items by means of investigation actions, is carried out by verifying the transactions that do not cross-match automatically and resolving the pending items through the due departments or counterparty in question. Generally, in the banking industry there is a widespread inhomogeneity between the solutions adopted for optimising and automating the reconciliation process. Thus, they tend to be specific and proprietary, so as to meet the needs of each counterparty to the uttermost. Despite the continuous technological evolution and the presence of increasingly pervasive management and accounting systems that are computerised and connected to the net, the management of inter-bank relationships still remains a field affected by many criticalities and problems relating to interoperability and automation.
A first problem lies in the process times: the times required to reconcile the inter-bank relationships are quite long, typically monthly due to the due to the extension of a consolidated and established practice relating to the reaching of a widespread consensus by the banks over time.
Furthermore, as concerns some pairs of banks that have financial relations standards and procedures that have at times gone beyond inter-bank agreements have been adopted over the years for various reasons. This precarious uniformity of rules makes it particularly challenging to effectively automate the inter-bank reconciliation process in that an all- inclusive system would become rapidly unfeasible, having to manage an excessively high number of exceptions and particular cases.
A further problem regards the transparency of the reconciliation operations in the current configuration. As a matter of fact, the method that is conventionally used for the reconciliation of mutual accounts provides for the periodic election of the owner of the reconciliation, whom is thus given the full responsibility of matching the transactions. Thus, the owner becomes the sole player with full access to the operations carried out, to the detriment of the counterparty who only plays a support role. Furthermore, the owner bank of the reconciliation will only use the systems thereof and the internal procedures which are not only different from those of the counterparty, but they are physically separated and inaccessible: this represents a clear problem in terms of communication and movement of information flow, to a point of leading, in some cases, a bank to losing visibility of its property. Lastly, alternating nature of the owner of the reconciliation requires the need to invert the process periodically. The inversion of the reconciliation is one of the most consuming and demanding operations which requires the re-aligning of the systems of the bank and taking up the history and records of the transactions. The entire process could even last months, with ensuing paralysis of the reconciliation and accumulation of pending items. Lastly, there is the problem regarding lack of interoperability of the accounting and management systems, which makes it necessary to implement interfaces and services for translating messages and representation of the data records. Over the years, given that each bank has its own protocols, modifying the previous agreements unilaterally, to guarantee and acceptable level of interoperability compromise and extraordinarily inefficient solutions are adopted, such as for example the previously mentioned exchange of documents in the absence of shared digital communication protocols. A possible more advantageous alternative to the use of proprietary communication systems lies in applying distributed digital ledger technology. However, the potential offered by DLT (Distributed Ledger Technology) does not solve the main problem observed, which still lies in the lack of uniform procedures, and thus requires the identification of more efficient and standardised process modes.
Though several patents addressing the matter are available internationally, such as the United States patent US20180046992, which provides for the use of distributed ledgers in the reconciliation, or patent n° W02017012054 regarding an inter-bank accounts reconciliation system, it is clear that none of them exhaustively addresses the criticalities outlined up to now. Description of the invention
According to the present invention, a method and system for the automatic reconciliation of inter-bank reports which effectively solves the aforementioned problems is provided. The proposed solution is based on a distributed digital infrastructure which interconnects the computer nodes of the banking institutes in question and which provides a reconciliation process in an automatic fashion using:
a shared ledger and accessible to any authorised person;
a set of communication and matching rules consisting of shared common rules and possibly specific rules;
a mechanism for the streamlining and progressive optimisation of the specific rules aimed at reducing the latter and automating the process.
The system may advantageously involve a predetermined number of players, with a minimum number of two and a maximum solely limited to the available technology and tendentially scalable at will. Hereinafter in the description, the expression players will be used to indicate any Entity or institution that needs to hold inter-bank relationships, this category thus including: banks and banking institutes, credit institutes, bank groups, financial organisations and the like.
The digital infrastructure will support a system of the of the distributed type and it will be obtained by providing each player with at least one processing node with characteristics suitable to appropriately process the input and output data flows. In particular, each processing node will be provided with the following minimum requirements:
one or more central processing units with possibility of parallel calculation and capacity of direct access to the memory;
a random-access central memory, co-located with respect to the processing unit and with dimensions sufficient to contain the programme data and workflows;
one or more local mass storage devices for the long-term preservation of the program data;
peripherals for interconnection and interfacing to the local network and to the external network included in the data switching and routing hardware;
access to external memory areas in the local network in form of additional storage
(NAS) or high-speed mass storage areas (SAN);
control terminals (local or remote).
Preferably, each processing node will be set up in the high reliability fail-safe configuration, both in terms of processing system and in terms of storage. Each node will be suitably completed with one or more back-up systems obtained in any manner suitable to allow the full restoration of efficiency following a damaging event.
The processing nodes network may be advantageously obtained according to any interconnection and communication protocol, including proprietary protocols specifically developed for the system in question. In the main embodiment the processing network will be developed vertically in compliance with the most common standards, such as for example the OSI model, with the aim of allowing greater compatibility and interoperability and for facilitating input into the node network and pre-existing infrastructures. Data traffic will advantageously be subjected to ciphering and the access, both physical and application, to the communication network will be rigidly subjected to a system of permissions and privileges. To this end, if necessary, the processing nodes of each player will be provided with control peripherals, data inspection and filtering (firewall, packet analyser, network traffic monitor). Lastly, if required by the service level agreements, it will be possible to implement a connections redundancy and network segments level, both inside and outside the processing infrastructure of each bank. Lastly, each single processing node will be provided with the required basic software (operating systems, drivers, programme interfaces, virtualisation systems, ...) and with the application software that obtains the method described hereinafter. Said application software will be suitably provided with man-machine graphic interfaces (GUI). Without affecting the general operating principle of the system, in some embodiments the application software can be implemented additionally and alongside the applications already used in the field of accounting/management, guaranteeing the interoperability thereof. In the cases requiring it, the software will see to executing the interface for translating and converting the input and output messages from the accounting systems already in use, with the aim of achieving full compatibility with the communication protocols of the system subject of the invention.
The core of the offered solution, as previously illustrated, lies in a method that implements a shared ledger, a set of common rules and a mechanism for incorporating the specific rules. Each of these characteristic aspects of the method will be described more in detail hereinafter.
A shared ledger is indispensable for tracing the transactions on mutual accounts, simultaneously guaranteeing the visibility of the entries to both parties. He sharing of the ledger advantageously allows overcoming the limitations entailed by the owner-based paradigm of the ledger and regarding the periodic inversion of the reconciliation, enhancing the strong points at the same time. By implementing a shared ledger, each player records the transactions thereof and has access to the entries carried out by the counterparty. It is thus possible to view the transactions without having to wait for the transfer of flows from the counterparty. The ledger may also be provided with autonomous capacity to process small code parts or a predefined set of instructions which act on the information contained therein without external supervision. Such capacity will for example be used to reduce, eliminate or automatically tore the items regarding transactions that already match according to the shared rules.
The ledger may conveniently be created through the possible implementations that can be obtained according to contemporary technique and practices. Such implementations include, but are not limited to: - Distributed filesystems;
shared storage areas connected in a network with access subjected to selective rules ( permissioning ) ;
distributed databases (DDBMS - Distributed DataBase Management System ) with controlled access;
storage nodes on network with peer nodes;
storage and processing cluster, such as the open source Hadoop project for example; Distributed Ledger Technology (DLT) of the permissioned type.
Irrespective of the technology used in the creation thereof, the shared register must always allow the players with inter-bank relationships full accessibility to the entries regarding the transactions thereof, simultaneously guaranteeing that no one else can obtain such access in any manner whatsoever without authorisation. Conveniently, third parties may possibly be involved solely as replication or redundancy nodes. A possible embodiment of the shared ledger may for example provide for each node of the system to:
- locally store and carry out full access to the ledger portion regarding one’s transactions towards another player;
locally store and carry out full access to the ledger portion regarding the transactions of the counterparties towards oneself;
locally storing one or more ledger portions without possibility of access regarding other transactions.
The part of the ledger not regarding one’s transactions stored by a node may be determined based on observations on redundancy and restoration of data integrity following the failure of one or more nodes (fault tolerance).
In order to allow high level of automation, the system will define a set of rules (ruleset) for matching the transactions on accounts regarding inter-bank relationships. The rules will be set based on parameters of computational efficiency, economicity of network traffic, replicability and reliability of the information contained therein and they will be natively and imperatively implemented on all network processing nodes. The aspects defined by the ruleset, regarding the reconciliation process comprise, but are not limited to: message and data flow format (record length, number and type of fields in the record, presence of checksum, etc.);
matching parameters (amounts, value dates, marks, direction of the transactions etc.);
- tolerance thresholds for the identification and possible reconciliation of physiological pending items;
pending items reconciliation suggestions.
In order to be able to flexibly adapt to the distinctive needs of each bank and for reflecting the agreements in force between one bank and the counterparty thereof as faithfully as possible, the system will advantageously allow the division of the ruleset into two categories of rules:
shared common rules: they have effect and validity in verifications and inspections of the transactions of all involved players and they are implemented on all nodes of the network and in the shared ledger globally;
specific supplementary rules: they are applied to a single, specific mutual account in the bank system and they are solely implemented on the nodes and in the items of the ledger involved. The specific rules may regard any aspect of the relationship, ranging from the data flow format to the pending items investigation procedures.
The pool of the defined shared rules simultaneously represents the crucial requirement for accessing the system and the pre-set level of ambition. As a matter of fact, according to the proposed model, each player who enters, at any level, into the automatic reconciliation system must adopt the shared set of rules. Such rules may be subsequently supplemented with possible specific additional information. However, the system provides for that the specific rules be progressively incorporated and supplemented in the shared rules through a polling process and periodic consent set as below:
- the specific rules are made known to all nodes;
- the system will group similar rules per category;
each player/node will express a binding preference to upgrade a rule from specific to global;
- the system will highlight any conflicts, re-proposing the choice; - the rules that will achieve a consensus will be incorporated in the set of global rules;
- the rules that will not achieve a consensus will remain valid for the involved parties only.
With the aim of constantly increasing the efficiency of the automatic mechanisms in force in the system, defined may be a number of specific rules which, at each polling cycle, must be compulsorily be eliminated for assimilation in shared common rules, with the set aim of eliminating any off-standard procedure. Such amount, the interval between polling cycles the type and number of consensus will depend on the particular embodiment based on the contingent needs. A possible implementation could for example require to incorporate 10% of the specific rules in the shared rules every two years and that the upgrade of a specific rules will require a simple majority consensus. The system may advantageously be provided with a subsystem for monitoring and tracing the use and the statistical occurrence of each specific rule, providing suggestions on the suitability of upholding it or not with the possibility of generating impact prediction scenarios. Lastly, the matching and investigation rules, both shared and specific, may be directly entered as an element or item of the shared ledger in form of instructions and lines of code to be carried out on the processing nodes. A further possibility may be the implementation of rules in the shared ledger like a smart contract.
Based on such rules, the system will be capable of automatically, and potentially in real time, carrying out the reconciliation process verifying the transactions, checking the status of the creditor and debtor, automatically reconciling the transactions and processing the pending items. Thus, the same rules will advantageously allow to separate the physiological pending items and the pending items subject of investigation and which require involving the counterparty. As concerns the latter case, it will be possible to decline an investigation procedure that exploits the potential of the network and the sharing of the transactions ledger so as to automate the flow processes regarding the transfer and breakdown of the operations, including those already reconciled, marginalising manual operations and limiting them to the most critical pending items and manual matching. In this sense, the proposed method will allow to reduce human intervention to the minimum and considerably increase the efficiency of the process.
Outlined below, purely by way of example, is a possible breakdown of the reconciliation process in stages, as can be obtained in the system subject of the invention:
entering transactions in the shared ledger;
automatic matching of the flows and transactions present in the ledger;
detection and identification of pending items;
investigation of pending items (automatic and semi-automatic);
correcting pending items under investigation.
Having an inherently distribute and shared architecture, the system may implement machine learning algorithms for tracing the manual activity of the operators and process suggestions to be subjected to the attention of the head of process with the aim of implementing new automatic rules.
Solely as concerns compulsorily manual operations, due to unreconciled flows that generate pending items due to reasons that cannot be otherwise identified and not reconcilable if not through human intervention, the automatic reconciliation system provided for, in the most complete embodiment, a support system that allows to use the resources of the processing network for:
- uniquely authenticating the person who carried out the manual intervention through a Multi-Factor Authentication (MFA);
Tracing the intervention and registering the metadata thereof on the shared media, allowing access thereto to the counterparty.
ensuring that the recording cannot be modified by the automated mechanisms: manual interventions may be retrieved and modified through manual intervention only.
The advantages provided by the present invention will be clear in light of the description outlined up to now. Furthermore, they will be more apparent due to the attached figures and relative detailed description.
Description of the figures The invention will be described hereinafter in at least one preferred embodiment, provided by way of non-limiting example, with reference to the attached figures, wherein:
- FIGURE 1 shows the representation of some possible transactions recorded on mutual accounts 520 and which require the reconciliation process 521 : shares 510, cheques 511, bank transfers 512 and accounts 513. The transfer of a transaction 525 in proprietary format on an accounting computer system 530 is illustrated.
- FIGURE 2 shows a possible embodiment of a general processing node 150 of the automatic reconciliation system, consisting of a central processor 151 provided with storage 153, accessory servers 152, access terminals 154 and ethernet connection 155 to the IP network 600 through firewall 156. The same figure also illustrates two possible configurations of the processing nodes network in which seven nodes, named 1501..1507, are connected to a star-like network 610 or in a peer to peer network 620.
- FIGURE 3 shows a possible logical implementation of the shared ledger 120 in a four- player system. Numbered are two banks 1501 and 1502 and the ledger portions written or stored by each: a mutual item 121, an exclusive relevance record 122 and an atomic fragment of the ledger 123.
- FIGURE 4 shows the process for polling and incorporating the rules 300. Numbered are various cycle steps for supplying the shared rules 310 which starts with the creation of specific rules 311 and, after a waiting period 312, it is subjected to a polling 313. The determination of the consensus 314 and the possible alternatives consisting in acceptation 316 or rejection 315.
- FIGURE 5 shows the flow chart of the automatic reconciliation process 200. The various process steps are illustrated and divided among the various peer nodes 1501 and 1502 and which share the digital ledger 125. The following are numbered: entering transactions 201, processing matching 202, identifying pending items 204, preliminary verification 203, internal investigation process 205 regarding shared records 207 assisted by automatically generated suggestions 206, possible manual correction 208 and entering reconciled transactions 209. One of the nodes has a mechanism for automatically generating suggestions 210 for the operator during reconciliation. In a second node, reference is made to an internal storage 211.
Detailed description of the invention
Hereinafter, the invention will be illustrated purely by way of a non-limiting or non-binding example, with reference to the figures illustrating some possible embodiments regarding the present inventive concept.
With reference to FIG. 1 a banking institute holding relationships 520 with one or more counterparties is taken for example. Entered into the mutual account are transactions of various origin and nature, such as: shares 510, cheques 511, bank transfers 512 and accounts 513. Each generated transaction is transferred to the accounting system 530 of the bank through a formatted message 525. The mutual nature of the accounts gives rise to the need of performing a reconciliation process 512 on the same so as to identify and reconcile mismatches, if present.
The automatic reconciliation system, in the distributed embodiment subject of the invention, includes all three key elements of the model:
- a shared ledger;
shared and specific matching rules;
a mechanism for incorporating the specific rules.
Furthermore, it should be observed that, according to the present embodiment, the system is scalable and extendable to an indefinite number of players/nodes.
Each player joining the system is provided with a processing node 150 which, with reference to FIG. 2, consists of a complex hardware/software and consisting of:
a central system 151 which provides the main processing capacity of the node;
one or more slaved servers 152 which have the secondary functions of web server, proxy, directory server for the authentication of users and services, etc.; a high capacity and high-performance storage sub-system 153, with direct access to the communication network (SAN);
one or more remote management terminals 154;
connectivity (155) and network security (156) elements;
The infrastructure will have access to the IP network 600 through channels that are secure, redundant and provided with an appropriate quality of service. The embodiment of the example will be provided with an operating system capable of managing true multitasking processes, parallel calculation, simultaneous access of several appliances and the concurrent and parallel use of hardware resources. The application software is specifically developed for obtaining the functionalities of the method described in detail hereinafter with reference to a flow chart in FIG. 5.
The processing nodes are shown in the figure with progressive numbers 1501 to 1507, for a system comprising seven players for the sake of brevity. Any type of network can be implemented: in the embodiment, the type is of the peer to peer 620 type with redundant connections and some centralised services.
The method is based on sharing information regarding transactions on accounts regarding inter-bank relationships and it provides for that the processing nodes have access to such information by implementing a shared ledger which, though maintaining the reconciliation owner concept, reduces the disadvantages thereof, in particular eliminating process asymmetries. In the embodiment in question (reference FIG. 3) the shared ledger 120 is implemented by means of a distributed database (DDBMS) with block redundancy and distributed peer control. There will also be the capacity to distinguish between data records and instructions records and it will be suitable to execute small code portions independently with the aim of reducing, eliminating and storing items regarding matching transactions according to the shared rules of the system.
The ledger is divided into elementary storage blocks 123 which are hierarchically aggregated in exclusive relevance records 122 which in turn form the items 121 of the ledger. Each item 121 contains one or more transactions regarding the same node and it thus consists of an exclusive relevance record of the first node and an exclusive relevance record of the second node, thus fully reflecting the symmetry of the transactions on the account. The illustration of FIG. 2 shows two nodes, named node“A” 1501 and node“B” 1502 which concurrently make entries in a ledger which contains the transactions of other nodes of the network. Each node locally contains a copy and full access to all items 121 containing records of their own relevance 122: hence, the nodes have immediate access to the transactions of the counterparty in the systems thereof. Additionally, to the items 121 thereof, when implementing the proposal, each node takes part in the fault tolerance strategy of the system by storing a copy of some selected elementary storage blocks 123 regarding the items of the other players, called external blocks. Contrary to the exclusive relevance records, such blocks cannot be accessed in reading, but remain available in the network in case of restoration. The number of nodes in the system taken for example, and the distribution strategy of the external blocks allow achieving tolerance to the loss of data of two nodes without affecting the system (full reconstruction of the ledger). As a matter of fact, in the example of the figure the node“A” 1501 locally has items“A-B”,“A-C” and“A-D” and it may preserve some blocks 123 of items“B-C”,“B-D” and“C-D”, but without the possibility of reconstructing the information contained therein.
In order to achieve the required automation level, the system provides for defining a set of shared rules (ruleset) for matching the transactions. The ruleset is optionally extendable by each counterparty with the addition of specific rules. In the proposed embodiment, the shared rules regard the following aspects:
JSON format for messages and records, length and number of fixed fields, aligned fields;
cause standards for all nodes;
periodicity for sending transactions on daily basis at most;
no aggregation of transactions;
a processing node for each bank;
automatic matching and generation of suggestions for manual reconciliation;
classification of pending items based on: amount, value date, mark.
Acceptation and implementation of the previous rules will be a compulsory requirement for access to the network by any new players. It will be possible to enter additional rules and unlimited validity to a pool of nodes (for example further specifications for classifying pending items) of said specific rules. The preferred embodiment allows entering specific rules directly on the shared ledger in form of smart contracts.
The model provides for that the specific rules be progressively thinned out and incorporated according to the polling process 300 illustrated in FIG. 3. According to such process, at time “zero” the system is based on a shared set of rules 310 to which a given number of specific rules 311 are added for each inter-bank relationship Periodically, at predefined intervals, the interval will be a shared rule, there will be carried out the interview and polling sub-process 313 to maintain or eliminate the status of specific rule. The result of the polling 314 will determine which rules will be accepted and converted 316 falling within the pool of shared rules and which will be rejected 315, remain specific. The process parameters are defined, considering the same interval as the polling cycle, in the shared rules. By way of example, in the proposed implementation, there may be:
- a three-year interval;
simplification of a given percentage of the specific rules at each cycle;
consensus required to accept a rule: unanimity.
Lastly, illustrated with reference to FIG. 5, is an automatic reconciliation process in case of two nodes“A” 1501 and“B” 1502 sharing the mutual portion of the shared ledger 120, represented by the ledger items 125. Each player acts independently and asynchronously with respect to the counterparty, carrying out the same operations in a mirror-like fashion. The illustrated steps are summarised below:
- the transactions that generate a transaction on the mutual account are stored 201 by each counterparty on the shared ledger portion thereof, within times compatible with the rules agreed upon (example: 1 day);
- the system automatically processes the transactions as soon as available, cross checking the mutual ledger items 202;
should mismatches be detected, the ledger signals them 204 to the counterparties, otherwise the process ends with the final entry of the transactions 209; each counterparty, as regards the relevant items thereof, checks the unreconciled items and decides on whether to carry out an investigation 205 or close the process;
- the investigation 205 may be supported by suggestions 206 generated by the system and considers all records contained in the ledger 207 without requiring to transfer flows from one node to the other;
each player has the prerogative to supplement the data stored in the shared ledger with archived evidence 211;
should a manual intervention be required 208, depending on the implementation, it is possible to request and obtain suggestions 210 from the system based on the actions taken in similar cases;
in any case, the process ends with the entry of the reconciled transactions and the system returns to the initial status.
Lastly, it is clear that the invention described up to now may be subjected to modifications, additions or variants obvious to a man skilled in the art, without departing from the scope of protection outlined by the attached claims.

Claims

Claims
1. Method and system for the automatic reconciliation of inter-bank relationships, characterised in that it is based on a distributed digital platform consisting of a network (620) of processing nodes (150) interconnecting an arbitrary and scalable number of banking institutes to which said nodes belong; said network having any topology and being provided with redundancy systems; said processing nodes having technical features and performance suitable to appropriately process the input and output flows; said technical features comprising at least: a) one or more central processing units (151); b) a central memory that is co-located with respect to the processing unit sufficient to contain programme data and workflows; c) one or more local mass storage devices; d) peripherals for interconnecting and interfacing with the local network (155) and with the external network (600); e) access to high performance memory and storage areas (153); f) local and remote control terminals (154); said processing nodes (150) also being configured for high reliability and designated for the back-up storage of data and programmes suitable for complete restoration of the functionality following a catastrophic event; said processing nodes (150) being provided with a basic software and an application level software implementing an automatic inter-bank relationships reconciliation process (520); said process being articulated in the following steps: 1) uploading transactions onto a shared storage device; 2) automatically matching the transactions present on the storage device; 3) detecting and reporting suspended transactions; 4) automatic and semi-automatic investigation of suspended transactions; 5) sorting out suspended transactions with possible manual action; said process being carried out by three key elements characterising the proposed reconciliation method: (A) a shared ledger (120) used for tracking and storing the transactions (520) by the processing nodes; thus, said transactions being visible and accessible to the parties in question in a controlled fashion; said ledger (120) enabling to verify and reconcile the entries and transactions on the accounts without having to wait for the flows to be submitted by the counterparty; said ledger being implemented according to any one of the technical solutions that exploit the distributed architecture of the system; said solutions include, but are not limited to: a) distributed file systems; b) shared networked storage areas with limited access; c) DDBMS distributed databases; d) peer to peer storage nodes; e) processing storage clusters; said ledger (120) enabling, irrespective of the implementation technology, each node the full access to the items (121) regarding the transactions thereof from and towards the others precluding unauthorised access; said ledger having autonomous processing capacity and being distinguishable between data records and instructions records, the latter being used to autonomously execute small operations without engaging network processing nodes; said operations comprising, but not being limited to reducing, eliminating, comparing and storing the items meeting predetermined matching criteria; said shared ledger (120) being protected against unauthorised modifications and accesses by means of cryptographic algorithms;
(B) a dynamic set of rules defining a) a communication and flow exchange protocol; b) a transactions verification, assessment and reconciliation criterion (< matching ); c) a method for investigating suspended transactions; said rules being natively implemented in the system; the acceptance and implementation of said rules forming a mandatory requirement by the new nodes to enable access to the network; said rules being divided into rules shared by all nodes (310) and specific rules (311) which unlimitedly extend the set of shared rules to a specific inter bank relationships between two nodes (150); said rules being recordable in the shared ledger in form of instruction records with the aim of enabling the automatic matching of the transactions in real time;
(C) a cyclic process (300) for streamlining and progressively optimising the specific rules (311) in the pool of shared rules (310) by means of a polling mechanism with consent; said process enabling the network nodes to reorganise the set of rules at pre-established intervals; said process having the following steps: 1) publishing the specific rules (311) grouped by categories; 2) collecting the binding preference of each node (150); 3) verifying the achievement of consent; 4) entering the selected rules into the set of shared rules (310); 5) maintaining specific rules (311) that do not achieve consent; said process being characterised by three parameters: a) the duration of the cycle; b) the type of consent required to establish the introduction of a rule into the set of shared rules (310); c) the minimum number of specific rules to be incorporated at each cycle.
2 Method and system for the automatic reconciliation of inter-bank relationships, according to the preceding claim 1, characterised in that said shared ledger (120) is obtained with one of the possible implementations enabled by the DLT technology for distributed digital ledgers.
3. Method and system for the automatic reconciliation of inter-bank relationships, according to the preceding claim 1, characterised in that said system is used for the automatic reconciliation of mutual accounts.
4. Method and system for the automatic reconciliation of inter-bank relationships, according to any one of the preceding claims 1 or 2, characterised in that said shared ledger (120) contains instructions records in form of smart contracts between the two counterparties holding a mutual account.
5. Method and system for the automatic reconciliation of inter-bank relationships, according to any one of the preceding claims, characterised in that said shared ledger
(120) is implemented using a distributed database with redundancy at elementary storage physical blocks level and distributed parity control; said ledger being hierarchically divided into elementary blocks (123) aggregated in exclusive relevance records (122) which in turn form, two by two, the items (121) of the ledger; said items
(121) containing one or more transactions regarding the same node (150); said items (121) being locally stored in the relevant nodes, which are allowed full access in a manner that is safe and with reduced times; said nodes (150) periodically synchronising said relevant items (121); lastly, said nodes (150) participating in the system fault tolerance strategy by memorising a pair of some selected elementary storage physical blocks (123) not regarding relevant records but without access thereto neither in terms of reading nor possibility of autonomously reconstructing the original record; said nodes
(150) managing an N number of blocks (123) not regarding relevant records sufficient to guarantee full reconstruction of the shared ledger (120) in case of irreversible loss of one or more network nodes. 6. Method and system for the automatic reconciliation of inter-bank relationships, according to any one of the preceding claims, characterised in that said process (300) for the progressive simplification of the specific rules through polling and consent of the processing nodes (150) is provided with a subsystem for monitoring and tracking the use and the statistical occurrence of each specific rule; said subsystem being capable of: a) providing, upon request, suggestions on which specific rules are to be maintained; b) generating use and impact prediction scenarios for each chosen option.
7. Method and system for the automatic reconciliation of inter-bank relationships, according to any one of the preceding claims, characterised in that the reconciliation process uses, in the suspended transactions investigation stage, suggestions generated automatically by the system to catalogue such suspended transactions and mark them as physiological or requiring further investigation.
8. Method and system for the automatic reconciliation of inter-bank relationships, according to any one of the preceding claims, characterised in that said system implements machine learning algorithms with the aim of supporting the activity for manual reconciliation of the suspended transactions; said algorithms using the records of manual actions carried out to process suggestions to be brought to the attention of the operators in charge of the process with the dual purpose of optimising the performance of the system during the manual action and identifying possible new matching rules to be introduced into the process.
9. Method and system for the automatic reconciliation of inter-bank relationships, according to any one of the preceding claims, characterised in that said system, solely as regards mandatory manual operations arising from suspended transactions not referring to any of the cases identified by the shared and specific rules, includes a support subsystem which enables utilising the processing network resources for: a) uniquely authenticating the person who performed the manual action through a Multi Factor Authentication method; b) tracking the manual action and recording the metadata thereof on the shared ledger (120) in a relevant item of the node in question simultaneously enabling access thereto by the counterparty; c) guaranteeing the non- editable status of the recording by the automatisms of the system; d) ensuring that access and editing of said record can only occur through a further manual action; said support subsystem being potentially integrated using personal identification portable electronic devices.
10. Method and system for the automatic reconciliation of inter-bank relationships, according to any one of the preceding claims, characterised in that said system includes, in the application software that implements the automatic reconciliation process, a component for interfacing with accounting computer systems already in use at the bank; said component being capable of translating and converting the input and output messages from the accounting systems with the aim of achieving full compatibility with the communication protocols defined by the rules specified in the proposed method.
PCT/IB2019/053632 2018-05-14 2019-05-03 Automatic inter-bank reconciliation system WO2019220251A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19729822.7A EP3794543A1 (en) 2018-05-14 2019-05-03 Automatic inter-bank reconciliation system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IT102018000005321 2018-05-14
IT102018000005321A IT201800005321A1 (en) 2018-05-14 2018-05-14 AUTOMATIC INTERBANK CHECK SYSTEM

Publications (1)

Publication Number Publication Date
WO2019220251A1 true WO2019220251A1 (en) 2019-11-21

Family

ID=63080316

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2019/053632 WO2019220251A1 (en) 2018-05-14 2019-05-03 Automatic inter-bank reconciliation system

Country Status (3)

Country Link
EP (1) EP3794543A1 (en)
IT (1) IT201800005321A1 (en)
WO (1) WO2019220251A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111429264A (en) * 2020-03-25 2020-07-17 中国工商银行股份有限公司 Combined account checking method and device for distributed system
CN111949660A (en) * 2020-08-12 2020-11-17 光大兴陇信托有限责任公司 Distributed comparison method based on HashMap data structure

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040030703A1 (en) * 2002-08-12 2004-02-12 International Business Machines Corporation Method, system, and program for merging log entries from multiple recovery log files
US7206805B1 (en) * 1999-09-09 2007-04-17 Oracle International Corporation Asynchronous transcription object management system
WO2017012054A1 (en) 2015-07-21 2017-01-26 深圳市银信网银科技有限公司 Interbank clearing method and system
US20180039667A1 (en) * 2016-08-05 2018-02-08 Chicago Mercantile Exchange Inc. Systems and methods for blockchain rule synchronization
US20180046992A1 (en) 2016-08-10 2018-02-15 Jpmorgan Chase Bank, N.A. Systems and methods for account reconciliation using a distributed ledger

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7206805B1 (en) * 1999-09-09 2007-04-17 Oracle International Corporation Asynchronous transcription object management system
US20040030703A1 (en) * 2002-08-12 2004-02-12 International Business Machines Corporation Method, system, and program for merging log entries from multiple recovery log files
WO2017012054A1 (en) 2015-07-21 2017-01-26 深圳市银信网银科技有限公司 Interbank clearing method and system
US20180039667A1 (en) * 2016-08-05 2018-02-08 Chicago Mercantile Exchange Inc. Systems and methods for blockchain rule synchronization
US20180046992A1 (en) 2016-08-10 2018-02-15 Jpmorgan Chase Bank, N.A. Systems and methods for account reconciliation using a distributed ledger

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111429264A (en) * 2020-03-25 2020-07-17 中国工商银行股份有限公司 Combined account checking method and device for distributed system
CN111949660A (en) * 2020-08-12 2020-11-17 光大兴陇信托有限责任公司 Distributed comparison method based on HashMap data structure

Also Published As

Publication number Publication date
IT201800005321A1 (en) 2019-11-14
EP3794543A1 (en) 2021-03-24

Similar Documents

Publication Publication Date Title
Coyne et al. Can blockchains serve an accounting purpose?
US11829997B2 (en) Self-enforcing security token implementing smart-contract-based compliance rules consulting smart-contract-based global registry of investors
US11475437B2 (en) Method and apparatus for managing subject data based on block chain
US20190392118A1 (en) Blockchain Version Control
US11216802B2 (en) Self-enforcing security token implementing smart-contract-based compliance rules consulting smart-contract-based global registry of investors
US20050261995A1 (en) Method and system for processing tax pertaining to a goods and services transaction
CN109472678B (en) Accounting book management method based on block chain, electronic device and readable storage medium
US20150095243A1 (en) Online-id-handling computer system and method
CN112883116A (en) Supply chain finance AI DaaS algorithm warehouse platform based on block chain
US20210312461A1 (en) Data sharing methods, apparatuses, and devices
KR101723865B1 (en) Method and system for personal information management in estimating credit rating of person to person banking using analysis of big data
WO2019220251A1 (en) Automatic inter-bank reconciliation system
Tkachuk et al. Towards efficient privacy and trust in decentralized blockchain-based peer-to-peer renewable energy marketplace
US20220284508A1 (en) A distributed computing architecture with settlement mechanism to enable traceability of credit tokenization, disbursement and repayment
CN104704521A (en) Multi-factor profile and security fingerprint analysis
CN113034275A (en) Management system and method based on block chain network and terminal equipment
CN117083603A (en) System for process coordination and interoperation across different systems, platforms and/or services
CN110910252A (en) System and method for managing security units associated with intellectual property assets
Silva et al. Blockchain implications for auditing: a systematic literature review and bibliometric analysis.
US20210082061A1 (en) Data governance system, model and process for multi-source financial reference data using automated business logic
US20210295283A1 (en) Methods and systems for blockchain digital currency stake delegation
CN113177772A (en) Service data processing method, device and system
Bauvars Applicability of Blockchain Technology in Securities Settlement.
Vincent et al. Blockchain or EDI
CN111275550A (en) Information processing method and device, readable storage medium and electronic equipment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19729822

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019729822

Country of ref document: EP

Effective date: 20201214