Patent Application
20190266580
The present disclosure relates in general to the field of computer systems, and more specifically, to digital security in computer network communications.
With the advent of the Internet and e-commerce, computing systems have been developed to enable many traditional banking and other financial transactions to be handled electronically. Slowing the adoption of such systems are lingering concerns that electronic transactions and accounts may be more susceptible to exploitation, or hacks, by unscrupulous actors. Despite the development of many security procedures and technologies governing data records, authentication, and communications in connection with electronic financial transactions, news stories continue to highlight the evolving variety of hacks, thefts, and other exploits endangering the assets of users and entities entrusting their transactions to modern banking and e-commerce systems.
According to one aspect of the present disclosure, an electronic financial transfer request may be received, which identifies that a first destination financial institution is a destination for a corresponding electronic financial transfer. An encrypted virtual wallet may be generated, which is encrypted by a key private to a first computing system associated with a second financial institution. The encrypted virtual wallet can be sent to a second computing system associated with the first financial institution. A transaction record is generated for the virtual wallet. The transaction record may be generated to identify the first destination financial institution, the transaction record private to the first computing system. Data may be received from a third computing system associated with a third financial institution to identify that the virtual wallet was transferred from the first financial institution to the third financial institution. The transaction record may be updated to identify that the virtual wallet was transferred from the first financial institution to the third financial institution.
According to another aspect of the present disclosure, an encrypted virtual wallet may be received from another computing system over a communications network. The virtual wallet corresponds to an electronic financial transfer and is received at a first electronic fund transfer system, associated with a first financial institution, from a second electronic fund transfer system associated with a second financial institution. The first financial institution may be identified from the virtual wallet and receipt data may be generated, which corresponds to the virtual wallet. The receipt data may be sent to the first electronic fund transfer system to report receipt of the virtual wallet by the second financial institution.
Like reference numbers and designations in the various drawings indicate like elements.
As will be appreciated by one skilled in the art, aspects of the present disclosure may be illustrated and described herein in any of a number of patentable classes or contexts, including any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. Accordingly, aspects of the present disclosure may be implemented entirely as hardware, entirely as software (including firmware, resident software, micro-code, etc.), or as a combination of software and hardware implementations, all of which may generally be referred to herein as a “circuit,” “module,” “component,” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied thereon.
Any combination of one or more computer readable media may be utilized. The computer readable media may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an appropriate optical fiber with a repeater, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain or store a program for use by, or in connection with, an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, CII, VB.NET, Python or the like, conventional procedural programming languages, such as the “C” programming language, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may execute entirely on a user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider), or in a cloud computing environment, or offered as a service such as a Software as a Service (SaaS).
Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatuses (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable instruction execution apparatus, create a mechanism for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that when executed can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions when stored in the computer readable medium produce an article of manufacture including instructions which when executed, cause a computer to implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer, other programmable instruction execution apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatuses, or other devices, to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Indeed, to facilitate transactions between banking computing systems (e.g., 105, 110), a specialized transaction network 115 may be defined (and facilitated over one or more private and/or public communication networks) to enable inter-system communication between banks to complete inter-bank transactions. For instance, a transaction network 115 may be implemented as a financial messaging network such as the Society for Worldwide Interbank Financial Telecommunication (SWIFT) network, the Financial Services Network (FSN), A Ripple Transaction Protocol (RTP) network, among other example implementations. In some implementations, access to the transaction network 115 may be tightly controlled, with access limited to accounts restricted to authorized banking professionals, specialized communication terminals or clients (e.g., 125, 130), among other example controls. While the transaction network 115 may assist in providing a level of trust and security to financial transactions conducted between banks (using their respective computing systems 105, 110), such trust and security may assume the trustworthiness and physical security of a bank. For instance, if a banking professional is compromised, who otherwise is permitted access to a corresponding banking computing system, the compromised banking professional may be leveraged to initiate fraudulent or wrongful bank transactions using the transaction network 115. Accordingly, in some implementations, additional technologies may be employed on top of the levels of security provided for implementing the transaction network 115 to guard against financial crimes, which may be carried out using the transaction network 115.
Modern banking customers have come to demand not only the ability to complete inter-bank transactions, but to have some visibility into their accounts, and thus the banking systems of their financial institutions. Accordingly, in some implementations, banking computing systems (e.g., 105, 110) may additionally provide connectivity to their users through public networks, (e.g., 120), such as the Internet. For instance, banking customers may utilize personal computing devices (e.g., 140, 145) to connect to a banking computing system 105, 110 through a public network 120. Users may thereby gain limited access to data and services directed related to their account by logging in and authenticating their device(s) (e.g., 140, 145) to perform online banking tasks, such as initiating wire transfers, performing intrabank and interbank money transfers, schedule bill payments, among other examples. In some instances, a transaction initiated by a user computing device (e.g., 140, 145) logged into a banking computing system (e.g., 105, 110) may cause messaging through transaction network 115 between banking computing systems (e.g., 105, 110), among other example scenarios and use cases.
In general, elements of computing environment 100, such as “systems,” “servers,” “services,” “hosts,” “devices,” “clients,” “networks,” “mainframes,” “computers,” and any components thereof (e.g., 105, 110, 115, 125, 130, 140, 145, etc.), may be used interchangeably herein and refer to electronic computing devices operable to receive, transmit, process, store, or manage data and information associated with computing environment 100. As used in this disclosure, the term “computer,” “processor,” “processor device,” or “processing device” is intended to encompass any suitable processing device. For example, elements shown as single devices within computing environment 100 may be implemented using a plurality of computing devices and processors, such as server pools comprising multiple server computers. Further, any, all, or some of the computing devices may be adapted to execute any operating system, including Linux, other UNIX variants, Microsoft Windows, Windows Server, Mac OS, Apple iOS, Google Android, etc., as well as virtual machines adapted to virtualize execution of a particular operating system, including customized and/or proprietary operating systems.
Further, elements of computing environment 100 (e.g., 105, 110, 115, 125, 130, 140, 145, etc.) may each include one or more processors, computer-readable memory, and one or more interfaces, among other features and hardware. Servers may include any suitable software component or module, or computing device(s) capable of hosting and/or serving software applications and services, including distributed, enterprise, or cloud-based software applications, data, and services. For instance, one or more of the described components of computing environment 100, may be at least partially (or wholly) cloud-implemented, “fog”-implemented, web-based, or distributed for remotely hosting, serving, or otherwise managing data, software services, and applications that interface, coordinate with, depend on, or are used by other components of computing environment 100. In some instances, elements of computing environment 100 may be implemented as some combination of components hosted on a common computing system, server, server pool, or cloud computing environment, and that share computing resources, including shared memory, processors, and interfaces.
While
Despite the security infrastructure in place within some banking transaction networks, such as the SWIFT messaging network, thieves, hackers, and other malicious actors continue to penetrate the banking system to facilitate damaging financial crimes. For instance, by compromising a bank employee or hacking into a banking computing system, a malicious actor may wrongfully transfer large sums of money from a victim bank to one or more target banks in order to steal the money that has been wrongfully transferred from the victim bank. To facilitate the success of such a heist, it is typical for the malicious actors to transfer these funds multiple time across multiple financial institutions—this adds complexity and time to assist the malicious actor in actually withdrawing the stolen cash and make the theft difficult to trace. In some cases, the ultimate goal of the malicious actor is to transfer the stolen funds to the bank of a country where money laundering and other financial criminal laws are lax or poorly enforced. When successful, financial crimes of this kind may it almost impossible to recover all of the stolen funds. These weaknesses in the global financial system, when unaddressed, will only encourage an increasing number of crimes of this kind. In some implementations, a cryptographic transaction, or wallet, may be defined and implemented using cryptographic logic implemented on banking computing systems to add an additional layer of security to interbank financial transactions, such as set forth in the examples below. Systems implementing such cryptographic wallets may address at least some of the example issues and shortcomings of existing systems above, among other example advantages.
Turning to
In one example, at least some banking system implementations may include a transaction path manager 205 to be used in association with virtual wallets generated in connection with financial transactions by a virtual wallet generator 215 implemented on the banking system (e.g., 105). A virtual wallet may be generated utilizing private cryptographic keys 225 obtained by or generated at the banking system (e.g., 105). A virtual wallet may be sent, in some cases, over a transaction network to represent cleared funds being transferred in a corresponding transaction. Banking systems (e.g., 105, 110) may include a transaction network client (e.g., 210a-b) to enable the banking system to connect to a corresponding transaction network (e.g., 115) and send messages over the network 115 to other banking systems. Virtual wallets generated by a banking computing system (e.g., 105) may be encapsulated in a message sent over the transaction network 115 in some implementations.
Receipt of a virtual wallet by a receiving banking system (e.g., 110) may trigger additional messaging, which may likewise be completed over a transaction network 115 (or another network (e.g., 120)). For instance, at least a portion of virtual wallet may be encrypted using a private key (e.g., 225) of the original source bank. Liquidation of funds within the wallet may be conditioned on the content of the virtual wallet being decrypted. Accordingly, a liquidating banking system (e.g., 110) may communicate with the source banking system (e.g., 105) over a network and request a copy of the private key or key pair for use in decrypting the virtual wallet. Receipt of the virtual wallet may also involve the sending of an acknowledgment message to the source banking system 105 to enable tracking of the virtual wallet and subsequent transfers of funds represented by the virtual wallet (which may be tracked using transaction path manager 205), among other example features. When a virtual wallet is decrypted, a proof of the decryption may be provided to the source banking system to confirm that the funds “within” the virtual wallet have been liquidated, resulting in the disposal of the virtual wallet and updating of transaction records (e.g., 230) to indicate that funds that were previously in the account of the source bank (e.g., as recorded in account records 234) have been successfully transferred and liquidated at a destination bank (e.g., 110) (which may or more may not be the initial destination of the funds transfer).
When virtual wallets are transmitted from one banking system (e.g., 105) to another (e.g., 110) in a transaction, the funds represented by the virtual wallet may be reflected as subtracted from the source account (e.g., in account records 234) and added to the account of the receiving bank (e.g., as expressed in account records 255). Accordingly, the receiving account may then forward the funds to a subsequent bank account, and so on. However, rules may be established such that the funds represented by the virtual wallet may not be liquidated without decryption of the virtual wallet. Further, rules may cause any bank receiving the virtual wallet to report the receipt of the virtual wallet to a source bank (e.g., corresponding to system 105) identified in the wallet. Should the overall funds of the wallet be divided (e.g., to keep some funds in one account and forward remaining wallet funds to another account, or to forward the funds of the account to multiple subsequent accounts, etc.) the bank desiring the division may request substitute wallets from the original source bank, as the wallet, as generated, corresponds to an undivided amount of funds, among other example implementations. A virtual wallet handler (e.g., 240) on a receiving banking system (e.g., 110) may include functionality for reporting the receipt of a virtual wallet to a source banking system (e.g., 105), requesting wallet splitting in response to detecting a request (e.g., through a user system 125, 130, 140) to divide funds of a received wallet, request a key corresponding to a virtual wallet (i.e., in response to detecting a requested liquidation event at the banking system 110), and decrypting the virtual wallet using a received key to enable liquidation of the virtual wallet's funds, among other example functionality.
While the example of
As noted above, user computing systems (e.g., 125, 130, 145, etc.) associated with banking professionals or account holders (or even malicious actors) may interface with banking systems (e.g., 105, 110) to cause transactions and communications between banking systems (e.g., over networks 115, 120). Interfaces (e.g., 220, 245) may be provided through the respective banking system (e.g., 105, 110), and based on the user (e.g., employee or customer), to enable the initiation and processing of various banking transactions. For instance, various graphical user interfaces (GUIs) may be provided through which a new funds transfer may be initiated. A GUI may be provided, for instance, to allow a customer (e.g., using computer 145) to request a wire or other fund transfer. Another GUI may be provided for access and use by a bank employee to request the generation and use of a virtual wallet to implement a requested fund transfer. In some cases, virtual wallets may be generated automatically for any bank-to-bank fund transfer, among other example implementations. Handling receiving virtual wallet-based fund transfers may also involve the use of a user interface. For instance, in some cases requesting a liquidation or wallet split may necessitate the involvement of a banking professional, to provide a level of oversight prior to the funds in a transaction being liquidated (e.g., as the liquidation of the funds makes recovery of those funds much more difficult). In some cases, the additional protections afforded by a virtual wallet or human-led liquidation request, etc. may be predicated on certain rules or machine-guided analyses of transactions (e.g., artificial intelligence or machine learning-assisted transaction analysis to detect suspicious transaction requests or activity), which may trigger the implementation of such safeguards, among other example implementations.
With the virtual wallet 250 and corresponding wallet record 230 generated, the banking system 105 of Bank A may transmit the encrypted virtual wallet to a banking computing system 110 associated with destination Bank B over a network. As noted above, in some cases, the virtual wallet 250 may be communicated as a message over a specialized bank transaction network. The recipient banking system 110 may receive the virtual wallet 250 and may identify a protocol associated with the virtual wallet. In this example, the banking system 110 may identify, from the virtual wallet 250, that Bank A is the original creator of the virtual wallet 250 and may further determine that the virtual wallet 250 was directly received from the system 105 associated with Bank A. Accordingly, the system 110 of Bank B may determine that no acknowledgement is needed to be sent from the system 110 of Bank B to the system 105 of Bank A (e.g., as Bank A is aware that the virtual wallet 250 was sent to the system 110 of Bank B. Further, upon receipt of the virtual wallet 250, the system 110 of Bank B may process the virtual wallet to identify the corresponding transfer of $50,000 and may update balances of one or more accounts (e.g., in accordance with a correspondent banking relationship) and perform a settlement in association with the transaction. The funds from the virtual wallet 250, however, may not be liquidated without decryption of the encrypted content 310 within the virtual wallet 250. Accordingly, the system 110 of Bank B may simply hold the virtual wallet 250 until a liquidation request is received from a user associated with the account receiving the funds of the virtual wallet 250.
Turning to
Continuing with the preceding example, prior to being liquidated, the virtual wallet 250 may be further transferred several more times to various other financial institutions. Indeed, in cases of a malicious actor and transfer, it may even be likely that such multiple transfers occur. Turning to
The process illustrated in
As shown in the example of
In the example of
Upon receiving the virtual wallet 250 at Bank B, a user (e.g., using device 125) may request that a first portion of the funds (e.g., $10,000) be transferred to an account at Bank C (e.g., 320), while a second portion of the funds (e.g., $40,000) be transferred to an account at Bank D (e.g., 330), among other example scenarios. When the system 110 of Bank B receives the multiple transfer requests 404, the system 110 may identify that a transfer of less than the entire value of the virtual wallet is requested. In response, the system may determine that the wallet 250 is to be “split” or divided in order to facilitate the request and preserve protection afforded through the virtual wallet. Accordingly, the system 110 may identify that Bank A is the originator of the virtual wallet 250 (and funds represented by the wallet 250) and may communicate with the system 105 associated with Bank A to request 406 new wallets to accommodate the multiple transfers 404. The request 406 may identify that the funds within the original wallet 250 are to be split into two or more pieces and the request 406 may identify the amount of each of these pieces (e.g., a $10K portion and a $40K portion).
Turning to
Upon generating the divided, child wallets 405, 410, the originating system 105 may send the child wallets to the requesting system 110. Upon receiving the child wallets 405, 410, the banking system 110 of Bank B may forward the received wallets 405, 410 to the respective banking systems (e.g., 320, 330) corresponding to the multiple transfer requests, which triggered the splitting of the original virtual wallet 250. For instance, in this example, the child wallet 405 corresponding to $10,000 is sent from Bank B 110 to Bank C 320, while the child wallet 410 corresponding to $40,000 is sent from Bank B 110 to Bank D 330. Continuing with this example, as shown in
After a wallet split event, each child wallet 405, 410 may be effectively handled and treated as a separate independent virtual wallet. For instance, as shown in the example of
It should be appreciated that the examples offered in connection with the preceding discussion are offered for illustrative purposes only. Indeed, the more generalized principles discussed and illustrated herein may equally apply to other alternative use cases and example transactions. For instance, multiple split events may take place at multiple different points in the transfer of what began as a single wallet to cause the generation of multiple child wallets. Some child wallets may not be transferred from the banking system, which requested the split, such as where one of the child wallets is transferred to another downstream system, while another child wallet is immediately subject to a liquidation request at the system, which requested the preceding wallet split, among other example situations. Indeed, virtual wallets may be applied in a variety of different transactions of varying complexities, involving various combinations of systems, and assets.
Turning to the example of
It should be appreciated that the flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various aspects of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order or alternative orders, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of any means or step plus function elements in the claims below are intended to include any disclosed structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The aspects of the disclosure herein were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure with various modifications as suited to the particular use contemplated.
