Intelligent distributed ledger consent optimizing apparatus for asset transfer

Aspects of the disclosure relate to processing asset transfers. A computing platform may receive an asset transfer request, and may modify a distributed ledger to include a new block corresponding to the asset transfer request. The computing platform may identify, for each of a plurality of consensus methods, a subset of existing blocks that, when used to perform the corresponding consensus method, uses a minimum number of the existing blocks to perform the corresponding consensus method. The computing platform may store, in the distributed ledger, block combinations having the minimum number for each of the plurality of consensus methods, and may execute, using each corresponding identified subset of the existing blocks, each of the plurality of consensus methods. Based on establishing the consensus, the computing platform may direct an event processing platform to process the asset transfer request, which may cause the event processing platform to process the request.

BACKGROUND

Aspects of the disclosure relate to processing asset transfer requests. In particular, one or more aspects of the disclosure relate to processing asset transfer requests using a distributed ledger.

In some instances, consensus among blocks of a distributed ledger may be used to validate and approve new blocks. In some instances, however, the process of obtaining such consensus may be inefficient and may require significant processing resources to perform. Accordingly, as distributed ledgers are increasingly adopted, it may be important to improve corresponding efficiencies.

SUMMARY

Aspects of the disclosure provide effective, efficient, scalable, and convenient technical solutions that address and overcome the technical problems associated with performing asset transfers. In accordance with one or more embodiments of the disclosure, a computing platform comprising at least one processor, a communication interface, and memory storing computer-readable instructions may receive an asset transfer request. The computing platform may extract, using deep learning based optical character recognition (OCR), information from the asset transfer request. The computing platform may identify a mining cluster for a stored distributed ledger. The computing platform may modify, using the mining cluster, the stored distributed ledger to include a new block corresponding to the asset transfer request. The computing platform may identify a consensus method by identifying, for each of a plurality of consensus methods, a subset of blocks from the stored distributed ledger that, when used to execute the corresponding consensus method, result in a lowest energy consumption value in comparison to remaining subsets of blocks. The computing platform may execute each of the plurality of consensus methods using the corresponding identified subsets of blocks. The computing platform may establish, based on execution of each of the plurality of consensus methods, consensus to process the asset transfer request. Based on establishing the consensus, the computing platform may send one or more commands directing an event processing platform to process an event corresponding to the asset transfer request, which may cause the event processing platform to process the event.

In one or more instances, the information may include one or more of: a financial institution corresponding to the asset transfer request, an amount of the asset transfer, a recipient account, or an originator account. In one or more instances, the computing platform may identify, using the information and a stored list of authenticated financial institutions, whether or not the financial institution corresponding to the asset transfer request is authenticated. Based on identifying that the financial institution corresponding to the asset transfer request is not authenticated, the computing platform may send an authentication request to an administrator computing device. Based on identifying that the financial institution corresponding to the asset transfer request is authenticated, the computing platform may proceed to establish whether or not the asset transfer request is genuine.

In one or more examples, establishing whether or not the asset transfer request is genuine may include identifying whether or not the originator account includes sufficient assets to perform the asset transfer. In one or more examples, based on identifying that the asset transfer request is not genuine, the computing platform may block the asset transfer. Based on identifying that the asset transfer request is genuine, the computing platform may perform the generation of the new block.

In one or more instances, the plurality of consensus methods may include one or more of: proof of work, proof of stake, proof of elapsed time, raft, proof of importance, proof of authority, proof of activity, proof of capacity, or proof of burn. In one or more instances, each subset of blocks may include a minimum number of blocks needed to establish consensus using the corresponding consensus method.

In one or more examples, the computing platform may store, in a governing block of the stored distributed ledger and after identifying the minimum numbers of blocks needed to establish consensus using each of the consensus methods, block combinations having the minimum number for each of the plurality of consensus methods. In one or more examples, the computing platform may receive a second asset transfer request. Instead of identifying the consensus method, the computing platform may execute, based on the minimum numbers of blocks stored in the governing block, each of the plurality of consensus methods on the minimum numbers of blocks to establish consensus for the second asset transfer request.

In one or more instances, the governing block may be configured to store a first set of minimum numbers of blocks for a first type of asset transfer requests and a second set of minimum numbers of blocks for a second type of asset transfer requests. In one or more instances, processing the event may include executing a fund transfer.

In one or more examples, the computing platform may receive a second asset transfer request. The computing platform may identify, by executing each of the plurality of consensus methods, that consensus is not established for the second asset transfer request. The computing platform may modify, based on identifying that consensus is not established, the stored distributed ledger to include a passive block representing the second asset transfer request.

In accordance with one or more additional or alternative embodiments of the disclosure, a computing platform comprising at least one processor, a communication interface, and memory storing computer-readable instructions may receive an asset transfer request. The computing platform may identify a mining cluster for a stored distributed ledger. The computing platform may modify, using the mining cluster, the stored distributed ledger to include a new block corresponding to the asset transfer request. The computing platform may identify a plurality of existing blocks comprising the stored distributed ledger. The computing platform may identify, for each of a plurality of consensus methods, a subset of the plurality of existing blocks that, when used to perform the corresponding consensus method: 1) uses a minimum number of the plurality of existing blocks to perform the corresponding consensus method, and 2) results in a lower energy consumption value than other possible subsets of the plurality of existing blocks. The computing platform may store, in a governing block of the stored distributed ledger, block combinations having the minimum number for each of the plurality of consensus methods, and may execute, using each corresponding identified subset of the existing blocks, each of the plurality of consensus methods. Based on establishing the consensus, the computing platform may send one or more commands directing an event processing platform to process an event corresponding to the asset transfer request, which may cause the event processing platform to process the event.

In one or more instances, the computing platform may extract, using deep learning based optical character recognition (OCR), information from the asset transfer request, where the information may be used to create the new block. In one or more instances, the information may include one or more of: a financial institution corresponding to the asset transfer request, an amount of the asset transfer, a recipient account, or an originator account.

In one or more examples, the computing platform may identify, using the information and a stored list of authenticated financial institutions, whether or not the financial institution corresponding to the asset transfer request is authenticated. Based on identifying that the financial institution corresponding to the asset transfer request is not authenticated, the computing platform may send an authentication request to an administrator computing device. Based on identifying that the financial institution corresponding to the asset transfer request is authenticated, the computing platform may proceed to establish whether or not the asset transfer request is genuine.

In one or more instances, establishing whether or not the asset transfer request is genuine may include identifying whether or not the originator account includes sufficient assets to perform the asset transfer. In one or more instances, based on identifying that the asset transfer request is not genuine, the computing platform may block the asset transfer. In one or more instances, based on identifying that the asset transfer request is genuine, the computing platform may generate the new block.

In one or more examples, the computing platform may establish, based on execution of each of the plurality of consensus methods, the consensus to process the asset transfer request. In one or more examples, the plurality of consensus methods may include one or more of: proof of work, proof of stake, proof of elapsed time, raft, proof of importance, proof of authority, proof of activity, proof of capacity, or proof of burn.

In one or more instances, the computing platform may receive a second asset transfer request. Instead of identifying the consensus method, the computing platform may execute, based on the minimum numbers stored in the governing block, each of the plurality of consensus methods on the minimum numbers of blocks to establish consensus for the second asset transfer request.

In one or more examples, the governing block may be configured to store a first set of minimum numbers of blocks for a first type of asset transfer requests and a second set of minimum numbers of blocks for a second type of asset transfer requests. In one or more examples, processing the event may include executing a fund transfer.

In one or more instances, the computing platform may receive a second asset transfer request. The computing platform may identify, by executing each of the plurality of consensus methods, that consensus is not established for the second asset transfer request. The computing platform may modify, based on identifying that consensus is not established, the stored distributed ledger to include a passive block representing the second asset transfer request.

DETAILED DESCRIPTION

In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown, by way of illustration, various embodiments in which aspects of the disclosure may be practiced. In some instances, other embodiments may be utilized, and structural and functional modifications may be made, without departing from the scope of the present disclosure.

As a brief introduction to the concepts described below, systems and methods for using a distributed ledger to manage asset transfer services are described herein. More specifically, asset transition services (ATS) operations teams deal in transfers of securities and cash through automated customer account transfers (ACAT), non-ACAT transfers (manual), annuity broker dealer and ownership changes, mutual fund transfers, and transfer paperwork requirements. It may act as a broker/dealer assisting with the transfer of client's incoming and outgoing assets. In the case of an erroneous delivery in or out of machine learning, ATS may perform reclaim activities where accounts are corrected.

Associates may review paperwork to validate transfers, notifying of any discrepancies/missing information through system messages in machine learning transfer systems emails or phone calls. Decisions of validation or rejection of the transfer request may lead to the following problems: 1) authenticity of a customer/asset transfer and securities manipulation, 2) non-association of smaller financial institutions with the network, 3) interbank communication and cumbersome follow up processes, 4) lack of end to end data tracking mechanisms, 5) dealing with multiple data inputs for transfer requests, 6) potential revenue loss due to incorrect delivery, and 7) manual efforts in processing documents/paperwork for asset transfer.

Accordingly, proposed herein is a solution to the above described problems that includes creating a blockchain based solution through which asset transfer may happen seamlessly. For example, a hybrid bagging consensus mechanism may be used to optimize energy in the blockchain using simulation of a combination of different nodes with various consensus methods. Additionally, consensus may be established among different parties to provide the ability to associate non-member banks within the blockchain. This may provide effective and efficient data tracking through the blockchain. In some instances, multiple channels may be leveraged to receive transfer requests to channelize the intake layer. Using computer vision and/or deep learning mechanisms, information may be validated and extracted for authentication.

As a result, the following benefits may be achieved: 1) optimized energy in the entire blockchain network using the best consensus, 2) seamless authentication and communication between financial institutions via block chain nodes, 3) facilitating addition of new smaller financial institutions in the asset transfer platform, 4) elimination of risk with flow of customer information via a distributed digital database secured network, and/or 5) channelizing requests via multiple modes to efficiently reduce the cycle time for asset transfer.

Accordingly, described herein is a system that employs the use of hybrid bagging consensus mechanisms to optimize energy in the blockchain using simulation of combinations of different nodes with various consensus methods, and that generalizes the model basis simulation of similar combinations of nodes and consensus.

FIGS.1A-1Bdepict an illustrative computing environment for an intelligent distributed ledger apparatus for asset transfer in accordance with one or more example embodiments. Referring toFIG.1A, computing environment100may include one or more computer systems. For example, computing environment100may include asset management platform102, client device103, administrator computing device104, and event processing platform105.

As described further below, asset management platform102may be a computer system that includes one or more computing devices (e.g., servers, server blades, or the like) and/or other computer components (e.g., processors, memories, communication interfaces) that may a distributed ledger and optimization techniques for asset transfer requests.

Client device103may be a laptop computer, desktop computer, mobile device, tablet, smartphone, or the like that may be used by an individual to request an asset transfer (e.g., a transfer of funds, stocks, and/or other assets between accounts hosted by different financial institutions). For example, the client device103may be operated by an individual such as a customer of a financial institution, an accountant, a financial advisor, and/or other individual. For example, the client device103may be used by one or more individuals to access a mobile application (e.g., a trading application, mobile banking application, or other application), a website (e.g., an online trading portal, online banking portal, and/or other website) and/or perform other functions. In some instances, client device103may be configured to display one or more user interfaces (e.g., interfaces that enable asset transfer requests, provide notification of event processing, and/or display other information).

Administrator computing device104may be a laptop computer, desktop computer, mobile device, tablet, smartphone, or the like that may be used by an employee of an enterprise organization (e.g., a financial institution, or the like). For example, the administrator computing device104may be used by one or more individuals to perform one or more tasks, process events, and/or perform other functions. More specifically, the administrator computing device104may be configured to maintain a list of registered/approved financial institutions that may participate in asset transfers. In some instances, administrator computing device104may be configured to approve new financial institutions and add them to the list.

Event processing platform105may be a computer system that includes one or more computing devices (e.g., servers, server blades, or the like) and/or other computer components (e.g., processors, memories, communication interfaces) that may be configured to process events based on commands or direction from the asset management platform102. For example, the event processing platform105may be configured to process a fund transfer, stock transfer, and/or other asset transfer between accounts.

Computing environment100also may include one or more networks, which may interconnect asset management platform102, client device103, administrator computing device104, and event processing platform105. For example, computing environment100may include a network101(which may interconnect, e.g., asset management platform102, client device103, administrator computing device104, and/or event processing platform105).

In one or more arrangements, asset management platform102, client device103, administrator computing device104, and/or event processing platform105may be any type of computing device capable of sending and/or receiving requests and processing the requests accordingly. For example, asset management platform102, client device103, administrator computing device104, event processing platform105, and/or the other systems included in computing environment100may, in some instances, be and/or include server computers, desktop computers, laptop computers, tablet computers, smart phones, or the like that may include one or more processors, memories, communication interfaces, storage devices, and/or other components. As noted above, and as illustrated in greater detail below, any and/or all of asset management platform102, client device103, administrator computing device104, and/or event processing platform105, may, in some instances, be special-purpose computing devices configured to perform specific functions.

Referring toFIG.1B, asset management platform102may include one or more processors111, memory112, and communication interface113. A data bus may interconnect processor111, memory112, and communication interface113. Communication interface113may be a network interface configured to support communication between asset management platform102and one or more networks (e.g., network101, or the like). Memory112may include one or more program modules having instructions that when executed by processor111cause asset management platform102to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor111. In some instances, the one or more program modules and/or databases may be stored by and/or maintained in different memory units of asset management platform102and/or by different computing devices that may form and/or otherwise make up asset management platform102. For example, memory112may have, host, store, and/or include asset management module112a, asset management database112b, and machine learning engine112c.

Asset management module112amay have instructions that direct and/or cause asset management platform102to execute advanced techniques for asset transfer management. Asset management database112bmay store information used by asset management module112aand/or asset management platform102in application of advanced distributed ledger management techniques for asset transfer processing, and/or in performing other functions. Machine learning engine112cmay have instructions that direct and/or cause the asset management platform102to set, define, and/or iteratively refine optimization rules and/or other parameters used by the asset management platform102and/or other systems in computing environment100.

FIGS.2A-2Gdepict an illustrative event sequence for an intelligent distributed ledger apparatus for asset transfer in accordance with one or more example embodiments. Referring toFIG.2A, at step201, the client device103may receive an asset transfer request. For example, the client device103may receive a request to transfer one or more assets (e.g., funds, stocks, and/or other assets) from an account corresponding to a first financial institution to an account corresponding to a second, different financial institution (e.g., not an internal transfer). In some instances, the client device103may receive the asset transfer request via a mobile application, a website, or other method from an individual such as a customer, accountant, financial advisor, or other individual.

At step202, the client device103may establish a connection with asset management platform102. For example, the client device103may establish a first wireless data connection with the asset management platform102to link the client device103to the asset management platform102(e.g., in preparation for sending the asset transfer request). In some instances, the client device103may identify whether or not a connection is already established with the asset management platform102. If a connection is already established with the asset management platform102, the client device103might not re-establish the connection. If a connection is not yet established with the asset management platform102, the client device103may establish the first wireless data connection as described herein.

At step203, the client device103may send the asset transfer request. For example, the client device103may send the asset transfer request while the first wireless data connection is established.

At step204, the asset management platform102may receive the asset transfer request sent at step203. For example, the asset management platform102may receive the asset transfer request via the communication interface113and while the first wireless data connection is established. In some instances, in receiving the asset transfer request, the asset management platform102may receive an electronic form that includes information related to the asset transfer request.

At step205, the asset management platform102may extract information from the asset transfer request (e.g., from the electronic form). For example, the asset management platform102may perform deep learning optical character recognition (OCR) to extract the information. In some instances, the asset management platform102may extract all or a portion of the information included in the asset transfer request. For example, the asset management platform102may extract one or more of: an originator financial institution corresponding to the asset transfer request, a recipient financial institution corresponding to the asset transfer request, an amount of the asset transfer (e.g., an amount of funds, quantity of stocks, or the like), a recipient account, an originator account, and/or other information that may be used to verify and/or perform the requested asset transfer. In some instances, the asset management platform102may be a cloud based computing platform and/or may otherwise communicate with a cloud based computing platform to store the extracted information in the cloud.

Referring toFIG.2B, at step206, the asset management platform102may identify whether or not the financial institutions (e.g., the originator and/or the recipient) corresponding to the asset transfer request are authenticated. For example, the asset management platform102may maintain a stored list of financial institutions that are authenticated (e.g., by a federal agency or other method), and may compare the financial institutions to the list. If the asset management platform102identifies that both financial institutions are authenticated, the asset management platform102may proceed to step213inFIG.2C. If the asset management platform102identifies that one or more of the financial institutions corresponding to the asset transfer request are not authenticated, the asset management platform102may proceed to step207.

At step207, the asset management platform102may establish a connection with the administrator computing device104. For example, the asset management platform102may establish a second wireless data connection with the administrator computing device104to link the asset management platform102to the administrator computing device104(e.g., in preparation for sending an authentication request). In some instances, the asset management platform102may identify whether or not a connection is already established with the administrator computing device104. If a connection is already established with the administrator computing device104, the asset management platform102might not re-establish the connection. If a connection is not yet established with the administrator computing device104, the asset management platform102may establish the second wireless data connection as described herein.

At step208, the asset management platform102may send an authentication request to the administrator computing device104, requesting that one or more of the financial institutions corresponding to the asset transfer request be authenticated. For example, the asset management platform102may send the authentication request to the administrator computing device104via the communication interface113and while the second wireless data connection is established.

At step209, the administrator computing device104may receive the authentication request sent at step208. For example, the administrator computing device104may receive the authentication request while the second wireless data connection is established.

At step210, the administrator computing device104may authenticate the financial institution. For example, the administrator computing device104may communicate with one or more computing systems corresponding to a federal agency and/or perform other techniques to authenticate the financial institution. For example, the administrator computing device104may verify that the financial institution is a valid entity and is reputable for purposes of engaging in the requested asset transfer.

Referring toFIG.2C, at step211, if the administrator computing device104successfully authenticates the financial institution, it may register the financial institution so as to add the financial institution to the stored list of authenticated financial institutions. In these instances, the administrator computing device104may generate a private key corresponding to the financial institution that may be used by the asset management platform102to authenticate future requests involving the financial institution. If the administrator computing device104identifies that the financial institution is not authenticated, it may proceed to step212without adding the financial institution to the list of authenticated financial institutions (and may, in some instances, add the financial institution instead to a list of prohibited financial institutions).

At step212, the administrator computing device104may communicate with the asset management platform102to notify the asset management platform102of the authenticated financial institution (e.g., and the asset management platform102may add the stored list of authenticated financial institutions). If the administrator computing device104identifies that the financial institution is not authenticated, it may notify the asset management platform102that the asset transfer request should not be executed.

At step213, the asset management platform102may establish whether or not the asset transfer request is genuine. For example, the asset management platform102may use the information extracted at step205to identify whether the originator account includes sufficient assets to perform the transfer request. For example, the asset management platform102may compare the assets of the originator account with the assets requested to be transferred. If the assets of the originator account are sufficient to perform the transfer, the asset management platform102may identify that the asset transfer request is genuine, and may proceed to step215inFIG.2D. If the assets of the originator account are insufficient to perform the transfer, the asset management platform102may identify that the asset transfer request is not genuine, and may proceed to step214.

At step214, the asset management platform102may block the requested asset transfer. For example, the asset management platform102may prevent the requested assets from being transferred from the originator account to the target recipient account.

Referring toFIG.2D, at step215, the asset management platform102may identify a mining cluster for a stored distributed ledger. In some instances, the asset management platform102may have previously identified the mining cluster (e.g., before receipt of the asset transfer request). For example, the asset management platform102may have generated the distributed ledger prior to receipt of the asset transfer request at step201, and may have then stored the distributed ledger for use in processing the asset transfer request. However, for illustrative purposes, identification of the mining cluster is described at this point in the event sequence.

To do so, the asset management platform102may access a knowledgebase that may include an optimal number of computational resources that may be used to mine the distributed ledger (e.g., the number of computational resources that may balance maximizing accuracy while minimizing the number of resources used).

At step216, the asset management platform102may generate a new block for the distributed ledger. For example, the asset management platform102may use the extracted information and the mining cluster to generate the block. In some instances, the asset management platform102may compute a hash of a previous block in the distributed ledger, and include the hash in the new block. Once the new block is generated, the asset management platform102may modify the distributed ledger to include the new block.

At step217, the asset management platform102may identify a consensus method for use in verifying that the asset transfer request should be processed. For example, rather than selecting a single consensus method and applying that method to all blocks of the distributed ledger (which might not result in the most accurate consensus) or applying every consensus method of a plurality of consensus methods to every block of the distributed ledger, the asset management platform102may use an optimizer to identify a most efficient consensus method. For example, the asset management platform102may use the optimizer to identify a minimum number of blocks to which each of a plurality of consensus methods may be applied (e.g., a first minimum number for a first consensus method, a second minimum number for the second consensus method, or the like), while still yielding an accurate result. To do so, the asset management platform102may identify, for each of a plurality of consensus methods, each block in the distributed ledger that has information related to each consensus method, perform random sampling, and/or use other techniques to identify these minimum numbers. In doing so, the asset management platform102may use a hybrid bagging consensus method to identify an optimal combination of particular consensus methods applied to particular blocks of the distributed ledger while minimizing processing resources/energy usage (e.g., because consensus need not be determined between all blocks, but rather simply a subset). For example, the asset management platform102may identify, for each of a plurality of consensus methods, a subset of blocks from the distributed ledger that, when used to execute the corresponding consensus method, result in a lowest energy consumption value in comparison to remaining subsets of blocks. In some instances, the asset management platform102may first determine the minimum number of blocks to achieve consensus for each consensus method, and then may perform, for each consensus method, a bagging method to identify a sample set of blocks that complies with the corresponding minimum number for each particular consensus method.

For example, the asset management platform102may identify that the distributed ledger includes blocks1-5. In this example, the asset management platform102may identify that a first consensus method should be applied to blocks1,2, and4, whereas a second consensus method should be applied to blocks3and4. In this example, performing the first consensus method using blocks1,2, and4may consume less energy and/or computing resources than, for example, if the first consensus method were to be applied to blocks2,3, and5.

With regard to the plurality of consensus methods, the asset management platform102may identify a minimum number of blocks to which to apply proof of work, proof of state, proof of elapsed time, raft, proof of importance, proof of authority, proof of activity, proof of capacity, proof of burn, and/or other consensus methods. In some instances the asset management platform102may apply a subset of the consensus methods (e.g., rather than applying every method).

After identifying the minimum number of blocks for each consensus method, the asset management platform102may store these minimum numbers, along with block combinations having the minimum number for each of the plurality of consensus methods, in a governing block of the distributed ledger. For example, in some instances, the asset management platform102may store simulations of combinations having a minimum number of different nodes tested/modelled with each of the consensus methods. In doing so, the asset management platform102may access the minimum numbers without repeating the optimization processes described at step217each time a new block is added. For example, if a second asset transfer request were to be received, rather than performing the optimization/method selection described above, the asset management platform102may simply consult the governing block to identify minimum numbers of blocks to which each consensus method should be applied (e.g., and subsequently execute, using each corresponding identified subset of the existing blocks, each of the plurality of consensus methods). Nevertheless, in some instances, the asset management platform102may periodically update the governing block (e.g., as new blocks are added to the distributed ledger, as new consensus methods are established, and/or for other reasons) so as to maintain optimization of the consensus method. In some instances, the asset management platform102may store different minimum numbers in the governing block (or in another governing block) corresponding to different use cases. For example, the asset management platform102may identify and store first numbers for fund transfers, and second number for stock transfers (or transfer of other types of assets).

At step218, the asset management platform102may use the identified consensus method from step217to identify whether or not consensus is established, among the distributed ledger, for the new block. For example, the asset management platform102may apply each consensus method to the corresponding identified subset of blocks in the distributed ledger (e.g., which may be the minimum number of blocks identified for each consensus method). This may result in the asset management platform102generating a value of “consensus achieved” or “consensus not achieved” (or something to that effect). This method described in steps216-218is further illustrated with regard toFIG.5, which is described below.

Referring toFIG.2E, at step219, the asset management platform102may identify whether or not the consensus was accepted. For example, if the consensus was accepted (e.g., consensus achieved), the asset management platform102may proceed to step221. In contrast, if the consensus was not accepted (e.g., no consensus), the asset management platform102may proceed to step220.

At step220, the asset management platform102may add a passive block, corresponding to the requested asset transfer, to the distributed ledger. In doing so, the asset management platform102may add a block that indicates the attempt to perform the requested asset transfer for record keeping purposes, but might not actually process the requested asset transfer, and thus might not include processing information in the block. In these instances, the asset management platform102may include information in the block indicating that consensus was not achieved for the requested asset transfer. Subsequently, the event sequence may end.

At step221, the asset management platform102may add a regular block to the distributed ledger. For example, the asset management platform102may add a block indicating that consensus was achieved and, in some instances, may include processing information for the requested asset transfer.

At step222, the asset management platform may establish a connection with the event processing platform105. For example, the asset management platform102may establish a third wireless data connection with the event processing platform105to link the asset management platform102to the event processing platform105(e.g., in preparation for sending an event processing request). In some instances, the asset management platform102may identify whether or not a connection is already established with the event processing platform105. If a connection is already established with the event processing platform105, the asset management platform102might not re-establish the connection with the event processing platform105. If a connection is not yet established with the event processing platform105, the asset management platform102may establish the third wireless data connection as described herein.

Referring toFIG.2F, at step223, based on or in response to establishing the consensus, the asset management platform102may send one or more commands directing the event processing platform105to process an event. For example, the asset management platform102may send a request to process the requested asset transfer (e.g., transfer funds, stocks, and/or other assets). In some instances, the asset management platform102may send the event processing request to the event processing platform105via the communication interface113and while the third wireless data connection is established.

At step224, the event processing platform105may receive the one or more event processing commands sent at step223. For example, the event processing platform105may receive the event processing request while the third wireless data connection is established.

At step225, based on or in response to the one or more commands, the event processing platform105may process the event corresponding to the asset transfer request. For example, the event processing platform105may transfer funds, stocks, and/or other assets from the originator account to the recipient account specified in the asset transfer request. In some instances, the event processing platform105may deduct one or more assets (e.g., on behalf of a processing entity, financial institution, or the like) from the total amount of assets being transferred prior to processing the event.

At step226, the event processing platform105may establish a connection with the client device103. For example, the event processing platform105may establish a fourth wireless data connection with the client device103to link the event processing platform105to the client device103(e.g., in preparation for sending event processing confirmation information). For example, the event processing platform105may identify whether or not a connection is already established with the client device103. If a connection is already established with the client device103, the event processing platform105might not re-establish the connection. If a connection is not yet established with the client device103, the event processing platform105may establish the fourth wireless data connection as described herein.

At step227, the event processing platform105may send event processing confirmation information indicating that the asset transfer request has been satisfied. In some instances, the event processing platform105may also send one or more commands directing the client device103to display the event processing confirmation information. In some instances, the event processing platform105may send the event processing confirmation information while the fourth wireless data connection is established.

At step228, the client device103may receive the event processing confirmation information. In some instances, the client device103may also receive the one or more commands directing the client device103to display the event processing confirmation information. In some instances, the client device103may receive the event processing confirmation information while the fourth wireless data connection is established.

Referring toFIG.2G, at step229, based on or in response to the one or more commands directing the client device103to display the event processing confirmation information, the client device103may display the event processing confirmation information. For example, the client device103may display a graphical user interface similar to graphical user interface405, which is illustrated inFIG.4, and that provides confirmation that the requested asset transfer has been successfully completed.

FIG.3depicts an illustrative method for an intelligent distributed ledger apparatus for asset transfer in accordance with one or more example embodiments. Referring toFIG.3, at step305, a computing platform having at least one processor, a communication interface, and memory may receive an asset transfer request. At step310, the computing platform may extract information from the asset transfer request. At step315, the computing platform may identify whether or not a financial institution corresponding to the asset transfer request is authenticated. If the financial institution is authenticated, the computing platform may proceed to step330. If the financial institution is not authenticated, the computing platform may proceed to step320.

At step320, the computing platform may send an authentication request to an administrator computing device. At step325, the computing platform may receive notification of registration of the financial institution.

At the330, the computing platform may identify whether or not the asset transfer request is genuine. If the asset transfer request is not genuine, the computing platform may proceed to step335. At step335, the computing platform may block the requested asset transfer, and the method may end.

Returning to step330, if the asset transfer request is genuine, the computing platform may proceed to step340. At step340, the computing platform may identify a mining cluster for a distributed ledger. At step345, the computing platform may use the mining cluster to generate a new block in the distributed ledger corresponding to the requested asset transfer. At step350, the computing platform may identify a consensus method for the distributed ledger. At step355, the computing platform may use the consensus method to establish consensus. At step360, the computing platform may identify whether or not consensus was achieved. If consensus was not achieved, the computing platform may proceed to step365. At step365, the computing platform may add a passive block to the distributed ledger representing the failed asset transfer request, and the method may end.

Returning to step360, if consensus was achieved, the computing platform may proceed to step370. At step370, the computing platform may add a regular block to the distributed ledger representing the successful asset transfer request. At step375, the computing platform may send an event processing request directing an event processing platform to process an asset transfer corresponding to the request.

FIG.5depicts an illustrative method for an intelligent distributed ledger apparatus for asset transfer in accordance with one or more example embodiments. At step505, a computing platform having at least one processor, a communication interface, and memory may generate a block (e.g., a block corresponding to an asset transfer request). At step510, the computing platform may receive a request to obtain consensus from a distributed ledger for the block. At step515, the computing platform may identify whether or not a consensus method is accessible from a governing block of the distributed ledger (e.g., a previously identified consensus method for energy optimization). If so, the computing platform may proceed to step525and perform the optimal energy consensus method to identify whether or not consensus is achieved with regard to the new block. If not, the computing platform may proceed to step520, and may use an optimizer to identify consensus method for energy optimization. For example, as described above with regard to step217, the computing platform may identify a minimum number of blocks in the distributed ledger to which each of a plurality of consensus methods should be applied. The computing platform may then proceed to step525to apply each of the plurality of consensus methods to a number of blocks (which may be selected through a bagging process) equal to the corresponding minimum number of blocks for each consensus method.