WO2024040226A1 - Secure computing platform - Google Patents

Abstract

A secure computing platform is provided. An exemplary method for facilitating secure transactions via encryption comprises: receiving, from a first user, one or more user-specified conditions for performing a secure transaction for an asset, wherein the asset is associated with an asset identifier; encrypting the asset identifier associated with the asset to obtain an encrypted identifier; constructing a new user request; transmitting the new user request to a transaction platform; inputting the new user request into an in-memory cache via an open data port; without the transaction platform identifying the asset, comparing, at the in-memory cache, the new user request to a pre-existing user request associated with a second user; and in accordance with certain determinations: storing the transaction to a persistent database and transmitting confirmation requests to electronic devices.

Description

SECURE COMPUTING PEATFORM CROSS-REFERENCE TO REEATED APPEICATION

[0001] This application claims the benefit of U.S. Provisional Application 63/399,589 filed on August 19, 2022, the entire contents of which are incorporated herein by reference for all purposes.

BACKGROUND

[0002] Electronic trading platforms used for transmitting trade interest requests from an investor user, for example, may typically rely on trusted intermediary users (e.g., broker users) to generate and distribute trade interest requests (e.g., Indications of Interest (IOIs)) via unsecure or less secure electronic trading platforms. In some instances, such trade interest requests may result in the misrepresentation of the investor user’s trading interest request, or otherwise information associated with the investor user’s trading interest request being published or advertised to adverse third-party users. Additionally, with the advent of many hedge funds or other similar financial organizations providing capital-as-a-service (CaaS), untrustworthy broker users may be incentivized to share trading interest requests to adverse third-party users that may actively trade on the information (e.g., block-trading) to the detriment of the original advertising or publishing investor user. It may be useful to provide a secured financial-trading computing platform for publishing or advertising trading interest requests of investors that do not rely on intermediary users (e.g., broker users).

BRIEF SUMMARY

[0003] Embodiments of the present disclosure include a secured financial-trading computing platform (e.g., a cloud-based computing platform) suitable for matching investor users (e.g., sellers or buyers) and interested party users (e.g., sellers or buyers), in which an investor user may be allowed to publish or advertise trading interest requests directly to the interested party users by way of smart advertisements. In certain embodiments, the smart advertisements may include one or more interactive electronic documents or data objects suitable for presenting information only in response to pre-specified conditions being met (e.g., by the interested party user). For example, in one embodiment, the investor user may determine the pre-specified conditions to be met before the smart advertisement presents information to the interested party user. In certain embodiments, the secured financial-trading computing platform may further monitor activity and behavior of all investor users on the secured financial-trading computing platform, and may continuously score and update a “credibility” (e.g., trustworthiness) metric or rating associated with the smart advertisements published or advertised by any of the investor users on the secured financial-trading computing platform.

[0004] For example, in one embodiment, the credibility metric or rating may include at least one user-specifiable criterion required to be satisfied before the smart advertisement presents information to an interested party user, and the user-specifiable criterion may be specified by the investor user at the time of publishing or advertising the smart advertisement. In certain embodiments, upon identification of matched trading interest requests that meet all criteria for bilateral exchange between, for example, the investor user and the interested party user, a notification may be then provided to the investor user that includes an indication that a match for an overlapping quantity (e.g., fiat currency value, cryptocurrency value, or other monetary value) has been determined and a selectable option for the investor user to accept the match. In certain embodiments, once accepted, the secured financial-trading computing platform may then provide to both the investor user and the interested party user a path or link including, for example, (1) an executing broker and (2) a password with which to tag trade orders sent from the investor user to the executing broker or from the interested party user to the executing broker. The executing broker, upon receiving trade orders with offsetting trade details and the same password, may then execute and report the trade interest (e.g., a trade order).

[0005] An exemplary method for facilitating secure transactions via encryption comprises: receiving, from a first user, one or more user-specified conditions for performing a secure transaction for an asset, wherein the asset is associated with an asset identifier; encrypting the asset identifier associated with the asset to obtain an encrypted identifier; constructing a new user request comprising the encrypted identifier and data associated with the one or more user- specified conditions; transmitting the new user request to a transaction platform; inputting, by the transaction platform, the new user request into an in-memory cache via an open data port, wherein the in-memory cache comprises the open data port and a plurality of closed data ports to prevent retrieval of the asset identifier from the in-memory cache, and wherein inputting the new user request comprises decrypting the encrypted identifier to obtain the asset identifier; without the transaction platform identifying the asset, comparing, at the in-memory cache, the new user request to a pre-existing user request associated with a second user; and in accordance with a determination that the asset identifier matches the pre-existing user request, and further in accordance with a determination that the pre-existing user request satisfies the one or more user- specified conditions of the new user request: storing the transaction to a persistent database; and transmitting a first confirmation request to a first electronic device of the first user and a second confirmation request to a second electronic device of the second user.

[0006] In some embodiments, the method further comprises receiving one or more user credentials from the first user; in accordance with a determination that the one or more user credentials are valid, generating a session key for the first user; and transmitting the session key to the first electronic device of the first user, wherein the identifier is encrypted based on the session key.

[0007] In some embodiments, the one or more user-specified conditions comprises: a price condition, a quantity, a user identifier, a credibility score associated with the first user, a time condition, a transaction type, or any combination thereof.

[0008] In some embodiments, the one or more user-specified conditions comprises: one or more brokers, a preference ranking related to the one or more brokers, a credibility score requirement, or any combination thereof.

[0009] In some embodiments, the method further comprises determining whether the preexisting user request satisfies the one or more user-specified conditions of the new user request at least partially by determining whether the pre-existing user request and the new user request share a common preferred broker.

[0010] In some embodiments, the one or more user-specified conditions comprises: a credibility requirement for the second user.

[0011] In some embodiments, the one or more user-specified conditions comprise one or more conditions for cancelling the new user request. [0012] In some embodiments, the method further comprises determining whether the one or more conditions for cancelling the new user request are met; and if the one or more conditions for canceling the new user request are met: foregoing sending the first confirmation request and the second confirmation request.

[0013] In some embodiments, the one or more conditions for canceling the new user request comprise a price condition for the asset, a performance condition for the asset, or any combination thereof.

[0014] In some embodiments, the method further comprises receiving a rejection by the first user in response to the first confirmation request; and reducing a credibility score associated with the first user based on the rejection.

[0015] In some embodiments, the method further comprises generating a new blockchain entry based on the reduction of the credibility score associated with the first user; adding the new blockchain entry to a blockchain associated with the credibility history of the first user.

[0016] In some embodiments, the method further comprises canceling the new user request in accordance with receiving the rejection.

[0017] In some embodiments, the method further comprises receiving a first acceptance by the first user in response to the first confirmation request; receiving a second acceptance by the second user in response to the second confirmation request; and transmitting a first password for the transaction to the first user and a second password for the transaction to the second user.

[0018] In some embodiments, the method further comprises presenting, via a remote terminal of a broker, the transaction between the first user and the second user; receiving the first password from the first user; receiving, via the remote terminal, confirmation that the first password was accepted; receiving the second password of the second user; receiving, via the remote terminal, confirmation that the second password was accepted; and in accordance with receipt of the confirmation that the first password was accepted and confirmation that the second password was accepted, executing the transaction based on the one or more user-specified conditions of the new user request. [0019] In some embodiments, the method further comprises increasing a credibility score associated with the first user based on the confirmation that the first password was accepted.

[0020] In some embodiments, the method further comprises: updating a credibility score associated with the first user based on: a first price of the asset before injecting the new user request; a second price of the asset after the first confirmation request is transmitted; a third price of the asset after the first confirmation request is responded to; or any combination thereof.

[0021] In some embodiments, the asset comprises a stock.

[0022] In some embodiments, the second user is a trader of the stock.

[0023] An exemplary system comprises: one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for: receiving, from a first user, one or more user-specified conditions for performing a secure transaction for an asset, wherein the asset is associated with an asset identifier; encrypting the asset identifier associated with the asset to obtain an encrypted identifier; constructing a new user request comprising the encrypted identifier and data associated with the one or more user- specified conditions; transmitting the new user request to a transaction platform; inputting, by the transaction platform, the new user request into an in-memory cache via an open data port, wherein the in-memory cache comprises the open data port and a plurality of closed data ports to prevent retrieval of the asset identifier from the in-memory cache, and wherein inputting the new user request comprises decrypting the encrypted identifier to obtain the asset identifier; without the transaction platform identifying the asset, comparing, at the in-memory cache, the new user request to a pre-existing user request associated with a second user; and in accordance with a determination that the asset identifier matches the pre-existing user request, and further in accordance with a determination that the pre-existing user request satisfies the one or more user- specified conditions of the new user request: storing the transaction to a persistent database; and transmitting a first confirmation request to a first electronic device of the first user and a second confirmation request to a second electronic device of the second user. [0024] An exemplary non-transitory computer-readable storage medium stores one or more programs, the one or more programs comprising instructions, which when executed by one or more processors of an electronic device having a display, cause the electronic device to perform: receiving, from a first user, one or more user-specified conditions for performing a secure transaction for an asset, wherein the asset is associated with an asset identifier; encrypting the asset identifier associated with the asset to obtain an encrypted identifier; constructing a new user request comprising the encrypted identifier and data associated with the one or more user- specified conditions; transmitting the new user request to a transaction platform; inputting, by the transaction platform, the new user request into an in-memory cache via an open data port, wherein the in-memory cache comprises the open data port and a plurality of closed data ports to prevent retrieval of the asset identifier from the in-memory cache, and wherein inputting the new user request comprises decrypting the encrypted identifier to obtain the asset identifier; without the transaction platform identifying the asset, comparing, at the in-memory cache, the new user request to a pre-existing user request associated with a second user; and in accordance with a determination that the asset identifier matches the pre-existing user request, and further in accordance with a determination that the pre-existing user request satisfies the one or more user- specified conditions of the new user request: storing the transaction to a persistent database; and transmitting a first confirmation request to a first electronic device of the first user and a second confirmation request to a second electronic device of the second user.

[0025] The embodiments disclosed above are only examples, and the scope of this disclosure is not limited to them. Particular embodiments may include all, some, or none of the components, elements, features, functions, operations, or steps of the embodiments disclosed above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] FIG. 1 is an example embodiment of a secured financial-trading computing platform.

[0027] FIG. 2 is an exemplary embodiment of a user interface associated with a secured financial-trading computing platform.

[0028] FIGS. 3A-3I are exemplary illustrations of one or more running examples of a secured financial-trading computing platform and user interface. [0029] FIG. 4 illustrates an example computer system.

[0030] FIG. 5 illustrates an exemplary platform.

[0031] FIG. 6 illustrates an exemplary process flow for securely matching a trade request between users.

[0032] FIGS. 7A-7M illustrate exemplary user interfaces.

[0033] FIG. 8A illustrates an exemplary process for completing a transaction via a broker.

[0034] FIGS. 8B-F illustrate exemplary user interfaces.

[0035] FIG. 8G illustrates an exemplary diagram illustrating how a broker is selected based on the user-specified path preferences.

[0036] FIGS. 8H-8J illustrate exemplary user interfaces.

[0037] FIGS. 9A-9C illustrate exemplary user interfaces.

[0038] FIG. 10 illustrates an exemplary process for matching a trade request of a user.

[0039] FIG. 11 illustrates an exemplary process for securely facilitating a transaction between a first user associated with a user request and a second user associated with a preexisting user request.

DETAILED DESCRIPTION

[0040] Particular embodiments disclosed herein may be designed to address specific problems or omissions in the current state of the art.

[0041] Particular embodiments disclosed herein may provide one or more of the following results, effects, or benefits. Embodiments of the present disclosure may provide a secured financial-trading computing platform suitable for reducing the frequency of adverse financial computing and trading activity including (1) aggregation (e.g., “scraping”) of financial trading interest requests private electronic trading platforms publically unavailable, (2) dissemination by broker users of trade interest requests to predatory investor users in exchange for trade orders or commission, (3) insider financial computing trading by trusted intermediary users exposed to sizable trade interest requests, (4) inaccurate advertising by broker users seeking order or flow.

[0042] Indeed, embodiments of the present disclosure include a secured financial-trading computing platform (e.g., a cloud-based computing platform) suitable for matching investor users (e.g., sellers or buyers) and interested party users (e.g., sellers or buyers), in which an investor user may be allowed to publish or advertise trading interest requests directly to the interested party users by way of smart advertisements. In certain embodiments, the smart advertisements may include one or more interactive electronic documents or data objects suitable for presenting information only in response to pre-specified conditions being met (e.g., by the interested party user). For example, in one embodiment, the investor user may determine the prespecified conditions to be met before the smart advertisement presents information to the interested party user. In certain embodiments, the secured financial -trading computing platform may further monitor activity and behavior of all investor users on the secured financial -trading computing platform, and may continuously score and update a “credibility” (e.g., trustworthiness) metric or rating associated with the smart advertisements published or advertised by any of the investor users on the secured financial-trading computing platform.

[0043] For example, in one embodiment, the credibility metric or rating may include at least one user-specifiable criterion required to be satisfied before the smart advertisement presents information to an interested party user, and the user-specifiable criterion may be specified by the investor user at the time of publishing or advertising the smart advertisement. In certain embodiments, upon identification of matched trading interest requests that meet all criteria for bilateral exchange between, for example, the investor user and the interested party user, a notification may be then provided to the investor user that includes an indication that a match for an overlapping quantity (e.g., fiat currency value, cryptocurrency value, or other monetary value) has been determined and a selectable option for the investor user to accept the match. In certain embodiments, once accepted, the secured financial-trading computing platform may then provide to both the investor user and the interested party user a path or link including, for example, (1) an executing broker and (2) a password with which to tag trade orders sent from the investor user to the executing broker or from the interested party user to the executing broker. The executing broker, upon receiving trade orders with offsetting trade details and the same password, may then execute and report the trade interest (e.g., a trade order).

[0044] FIG. 1 is an example embodiment of a secured financial-trading computing platform, in accordance with the presently disclosed embodiments. In certain embodiments, the secured financial-trading computing platform may include a cloud-based computing platform that may be hosted on one or more servers and stored to one or more encrypted databases associated with the one or more servers. As depicted, in certain embodiments, the secured financial-trading computing platform may include a web layer, a bank interface, an intermediate layer, a credibility monitor, a persistence layer, a validator, a matching engine, an event handler, a pathfinder, and a market monitor. In some embodiments, the web layer, the bank interface, the intermediate layer, the credibility monitor, the persistence layer, the validator, the matching engine, the event handler, the pathfinder, and the market monitor may each include, for example, a computing module executing software instructions, and may be implemented by the one or more servers of the secured financial-trading computing platform and stored on the one or more databases of the secured financial-trading computing platform.

[0045] In certain embodiments, the web layer may include cloud based servers that communicate with user interfaces distributed globally, receives password confirmation from the bank interface, and communicates with the intermediate layer. The bank interface may include an application programming interface (API) that receives confirmation of passwords received by brokers executing trade orders. The intermediate layer may include middleware that passes information to and from the web layer to the credibility monitor, the persistence layer, the pathfinder, the event handler, and the market monitor.

[0046] In certain embodiments, the credibility monitor tracks (1) smart advertisement uploads, (2) cancellation rate, (3) accept match rate, and (4) time between direction reversal on smart advertisements for the same stock for every user and updates the user’s credibility metric or rating in the persistence layer via the intermediate layer. The persistence layer may include a collection of databases for various purposes including, for example, audit, user data, IOI data for live advertisements, and transaction data for post-match accounting. All market sensitive data remains encrypted within databases. Data is received from users via the input screen or a file upload (e.g., comma-separated values (CSV) file) that serves the same function as the input screen. The validator combines user data (e.g., a user’s credibility metric or rating) and IOI data from the persistence layer into a smart advertisement. The validator also checks market data to confirm that a price trigger condition is met (if present), and then passes smart advertisements to the matching engine.

[0047] In certain embodiments, the matching engine, upon receipt of smart advertisement, searches for a match within the matching engine. For example, to qualify as a match, both advertisements may not be locked or expired; security is to be the same; direction is to be opposed; credibility ratings are to be bilaterally satisfied; smart advertisements are to have at least one common executing bank selected; user type is to bilaterally satisfy a “Show To . . .” condition; and quantity of smaller smart advertisement is to be greater than minimum quantity requirement of larger smart advertisement. If no match is found, a smart advertisement remains within the matching engine. Upon identification of a match, the matching engine locks contracts and sends a “Match Found” indication along with IOI identification numbers to the event handler. Upon receipt of “Cancel” instruction from the event handler, the matching engine removes related smart advertisement(s) from the matching engine. Upon receipt of “Unlock” instruction from the event handler, the matching engine removes locked status from related smart advertisement.

[0048] In certain embodiments, the event handler, upon receipt of a “Match Found” indication, sends mid-price request to the market monitor for matched security related to IOI identification numbers and sends a “Match Found” indication to the user via an intermediary and the web layers. Upon receipt of “Accept,” “Amend,” or “Cancel” instruction from the user, the event handler sends a “Cancel” instruction to the matching engine. Upon time-out of “Match Found” notification, the event handler sends a “Cancel” instruction to the matching engine for the party that failed to “Accept” and an “Unlock” instruction to the matching engine for the party that accepted the “Match.” Upon receipt of the “Accept” instruction from both related users in a “Match Found” scenario, the event handler sends IOI identification numbers to the pathfinder for path generation. The market monitor retrieves mid-price of a security to display to users notified by the event handler in a “Match Found” scenario. The pathfinder generates paths to execution for bilaterally accepted matched advertisements using data pulled from the persistence layer. The pathfinder sends paths to users via the intermediary and the web layers. Paths may include executing broker(s) and password(s).

[0049] FIG. 2 is an exemplary embodiment of a user interface associated with a secured financial-trading computing platform, in accordance with the presently disclosed embodiments. As depicted, the user interface may include an IOI pane, an indication detail pane, an advertising preference pane, a path preference pane, and an IOI search bar, as all discussed in greater detail below with respect to running examples including in FIGS. 3A-3I.

[0050] Particular embodiments may repeat one or more steps of the example process(es), where appropriate. Although this disclosure describes and illustrates particular steps of the example process(es) as occurring in a particular order, this disclosure contemplates any suitable steps of the example process(es) occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example process, this disclosure contemplates any suitable process including any suitable steps, which may include all, some, or none of the steps of the example process(es), where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the example process(es), this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the example process(es).

[0051] FIGS. 3A-3I are exemplary illustrations of one or more running examples of a secured financial-trading computing platform, in accordance with the presently disclosed embodiments. As illustrated by FIGS. 3A and 3B, the IOI upload process begins with the user interface, and the user input screen within the user interface (or a file upload that serves the same function as the user input screen). Fields from the input screen are passed through the web and the intermediate layers to the persistence layer for storage in various databases. User data (e.g., a user’s credibility metric or rating) is combined with the IOI data and passed to the validator. The validator converts the IOI data into a smart advertisement and checks to see if a price trigger has been specified. If a price trigger is not specified, the validator passes the smart advertisement to the matching engine. If a price trigger has been specified, the validator checks market data to confirm if the price trigger condition has been met. If met, the validator passes the smart advertisement to the matching engine. If not met, the validator adds smart advertisement to a pending queue. The validator periodically checks the queue to confirm if price trigger condition has been met for unexpired smart advertisements. The matching engine receives the smart advertisement.

[0052] As illustrated by FIGS. 3C and 3D, the “Match” notification process begins with the matching engine. When the matching engine has identified a match, the matching engine locks the smart advertisements and notifies the event handler of “Match Found.” The event handler notifies the user via the intermediary and the web layers of “Match Found,” and then requests mid-price of the security from the market monitor. The event handler sends a “Match Found” update to the persistence layer via the intermediate layer. The market monitor retrieves mid-price of the security from the market data and contributes to the “Match Found” notification sent to user via the intermediary and the web layers. The persistence layer updates the audit data, IOI data, and the user data to reflect “Match Found.”

[0053] As illustrated by FIG. 3E, “Match Acceptance” begins with the user interface, where the user accepts the “Match Found.” The event Handler receives an “Acceptance” indication via the web and the intermediate layers. The event handler sends IOI identification numbers to the pathfinder for path generation. The event handler sends a “Cancel” indication and IOI identification numbers to the matching engine for removal of smart advertisements. As illustrated by FIGS. 3F and 3G, path generation begins with the pathfinder. The pathfinder queries the persistence layer to retrieve path preferences for 101s, and then generates unique passwords tagged to matching quantities for the executing broker(s) that satisfy user’s path preference. The pathfinder then submits paths to users including, for example, executing broker(s), quantity, mid- price at time of “Match Found,” and password to be tagged on trade order(s) sent to executing broker(s).

[0054] As illustrated by FIG. 3H, path confirmation begins with the broker that received trade orders from investors directed by the matching engine. The broker notifies the web layer of receipt of passwords tagged to trade orders. The receipt notification is passed from the web layer through the intermediate layer to the persistence layer, in which audit data, user data, IOI data, and transaction data is updated. As illustrated by FIG. 31, IOI cancellation process begins with the user interface. A “Cancellation” indication by the user is passed through the web layer and the intermediate layers to the persistence layer and the event handler. The persistence layer updates audit, user, and IOI data to reflect cancellation. The event handler sends a “Cancel” notification to the matching engine. The matching engine removes relevant smart advertisements.

[0055] It should be appreciated that any of various potential use cases may be within the scope of the embodiments of the present disclosure. One or more use cases of the secured financial-trading computing platform may include an information escrow feature, which may be utilized for investments that are not listed equities, and, more specifically, alternative investments, bonds, derivatives, or private equity that may be executed or cleared by an independent third party. One or more additional use cases of the secured financial-trading computing platform may include the credibility monitoring, which may be applied beyond trading interests and trade order handling, such as user engagement and interaction via social media platforms, user engagement and interaction via financial service and payment platforms, user devices included within an Internet-of-Things (loT) ecosystem, and so forth. One or more additional use cases of the secured financial-trading computing platform may include applying a rules-based process for automatically adjusting credibility metric or rating, for example, for users in a dark pool investing exchange or platform.

[0056] In all example embodiments described herein, appropriate options, features, and system components may be provided to enable collection, storing, transmission, information security measures (e.g., encryption, authentication/authorization mechanisms), anonymization, pseudonymization, isolation, and aggregation of information in compliance with applicable laws, regulations, and rules. In all example embodiments described herein, appropriate options, features, and system components may be provided to enable protection of privacy for a specific individual, including by way of example and not limitation, generating a report regarding what personal information is being or has been collected and how it is being or will be used, enabling deletion or erasure of any personal information collected, and/or enabling control over the purpose for which any personal information collected is used.

[0057] FIG. 4 illustrates an example computer system 400. In particular embodiments, one or more computer systems 400 perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one or more computer systems 400 provide functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems 400 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems 400. Herein, reference to a computer system may encompass a computing device, and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate.

[0058] This disclosure contemplates any suitable number of computer systems 400. This disclosure contemplates computer system 400 taking any suitable physical form. As example and not by way of limitation, computer system 400 may be an embedded computer system, a system- on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on- module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these. Where appropriate, computer system 400 may include one or more computer systems 400; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 400 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example and not by way of limitation, one or more computer systems 400 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 400 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.

[0059] In particular embodiments, computer system 400 includes a processor 402, memory 404, storage 406, an input/output (I/O) interface 408, a communication interface 410, and a bus 412. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.

[0060] In particular embodiments, processor 402 includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor 402 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 404, or storage 406; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 404, or storage 406. In particular embodiments, processor 402 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 402 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 402 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory 404 or storage 406, and the instruction caches may speed up retrieval of those instructions by processor 402. Data in the data caches may be copies of data in memory 404 or storage 406 for instructions executing at processor 402 to operate on; the results of previous instructions executed at processor 402 for access by subsequent instructions executing at processor 402 or for writing to memory 404 or storage 406; or other suitable data. The data caches may speed up read or write operations by processor 402. The TLBs may speed up virtual-address translation for processor 402. In particular embodiments, processor 402 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 402 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 402 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 402. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.

[0061] In particular embodiments, memory 404 includes main memory for storing instructions for processor 402 to execute or data for processor 402 to operate on. As an example and not by way of limitation, computer system 400 may load instructions from storage 406 or another source (such as, for example, another computer system 400) to memory 404. Processor 402 may then load the instructions from memory 404 to an internal register or internal cache. To execute the instructions, processor 402 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 402 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 402 may then write one or more of those results to memory 404. In particular embodiments, processor 402 executes only instructions in one or more internal registers or internal caches or in memory 404 (as opposed to storage 406 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 404 (as opposed to storage 406 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 402 to memory 404. Bus 412 may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 402 and memory 404 and facilitate accesses to memory 404 requested by processor 402. In particular embodiments, memory 404 includes random access memory (RAM). This RAM may be volatile memory, where appropriate This RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory 404 may include one or more memories 404, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

[0062] In particular embodiments, storage 406 includes mass storage for data or instructions. As an example and not by way of limitation, storage 406 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 406 may include removable or non-removable (or fixed) media, where appropriate. Storage 406 may be internal or external to computer system 400, where appropriate. In particular embodiments, storage 406 is non-volatile, solid-state memory. In particular embodiments, storage 406 includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 406 taking any suitable physical form. Storage 406 may include one or more storage control units facilitating communication between processor 402 and storage 406, where appropriate. Where appropriate, storage 406 may include one or more storages 406. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

[0063] In particular embodiments, I/O interface 408 includes hardware, software, or both, providing one or more interfaces for communication between computer system 400 and one or more I/O devices. Computer system 400 may include one or more of these I/O devices, where appropriate. One or more of these I/O devices may enable communication between a person and computer system 400. As an example and not by way of limitation, an I/O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these. An I/O device may include one or more sensors. This disclosure contemplates any suitable I/O devices and any suitable I/O interfaces 408 for them. Where appropriate, I/O interface 408 may include one or more device or software drivers enabling processor 402 to drive one or more of these I/O devices. I/O interface 408 may include one or more I/O interfaces 408, where appropriate. Although this disclosure describes and illustrates a particular I/O interface, this disclosure contemplates any suitable I/O interface.

[0064] In particular embodiments, communication interface 410 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 400 and one or more other computer systems 400 or one or more networks. As an example and not by way of limitation, communication interface 410 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 410 for it. As an example and not by way of limitation, computer system 400 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 400 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN or ultra-wideband WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 400 may include any suitable communication interface 410 for any of these networks, where appropriate. Communication interface 410 may include one or more communication interfaces 410, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

[0065] In particular embodiments, bus 412 includes hardware, software, or both coupling components of computer system 400 to each other. As an example and not by way of limitation, bus 412 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 412 may include one or more buses 412, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

[0066] Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field- programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid- state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.

[0067] Herein, “or” is inclusive and not exclusive, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A or B” means “A, B, or both,” unless expressly indicated otherwise or indicated otherwise by context. Moreover, “and” is both joint and several, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A and B” means “A and B, jointly or severally,” unless expressly indicated otherwise or indicated otherwise by context.

[0068] Embodiments of the present disclosure may further provide systems and methods that allow a user (e.g., an investor) to securely place user requests (e.g., trade requests) on a transaction platform (e.g., a trading platform). As used herein, the term trade request may be used interchangeably with the term “indication of interest” or “IOI.” Embodiments of the present disclosure provide a platform that is secure on both the frontend and backend to allow frontend users (e.g., an investor) to place a trade request for an asset such as stock or security (also referred to as an underlier), match the trade request asset with a pre-existing trade request by a second user (e.g., a trader), and initiate the transaction (e.g., via a broker) once both users have accepted the trade request. Embodiments of the present disclosure further provide a secure platform such that backend users, such as employees of the transaction platform, are unable to identify the assets in any pending trade requests and conduct trading activities based on such information. In this manner, embodiments of the present disclosure provide a secure trading platform that improves security of conventional transaction platforms and reduces the likelihood of market manipulation.

[0069] Embodiments of the present disclosure further provide systems and methods for monitoring and updating the credibility of one or more users of the platform, such as investors, traders, brokers, etc. For example, the system can maintain a credibility score for each user and update the credibility score based on the user’s activities (e.g., whether the user refuses to go through with a transaction, frequency of acceptance) and price changes (e.g., the prices of the asset when the user places the request, when the user is notified of a matching, when the user accepts a transaction, and a time period after the execution of the transaction). The credibility rating of the users and brokers may be maintained on blockchain to provide a record and ensure the integrity of the credibility ratings.

[0070] Embodiments of the present disclosure provide numerous technical advantages. The platform prevents misrepresentation of a trade request of an investor by constructing a user request including user-specified conditions, such as price, quantity, preferred broker(s) and a detailed ranking, a credibility requirement for the trader, and/or one or more cancelling conditions for canceling the user request (e.g., based on price, performance, and the like). This ensures the resulting transaction to meet all requirements for the investor and prevents other parties from misrepresenting the need of the investor. Further, embodiments of the present disclosure leverage encryption and an in-memory cache to prevent the transaction platform from identifying the assets in the trade request unless and until the trade request is matched. This prevents information associated with the investor user’s trade requests from being published or advertised to adverse third-party users. Furthermore, by maintaining and updating users’ credibility scores, embodiments of the present disclosure can discourage bad actors from placing trade requests to extract information about the market, without intending to carry through the transactions. Accordingly, embodiments of the present disclosure allow secure transactions to be constructed and processed in an accurate and efficient manner, thus improving the functioning of the computer systems such as the memory usage and processing power.

[0071] FIG. 5 illustrates an exemplary platform 500 in accordance with embodiments of the present disclosure. The exemplary platform may include a gateway 520, an in-memory cache 530, one more databases 540, and a backend application 550. As shown in the figure, one or more users 502 may access the exemplary platform 500. The users 502 may access the platform 500 using a user interface via a user terminal. In some embodiments, the user terminal may correspond to local computer system (e.g., computer system 400). In some embodiments, the user terminal can access the user interface via a client web application distribution 510. In some embodiments, the user interface and/or web application may be in communication with the exemplary platform 500. In some embodiments, the user interface and/or web application may be in communication with the exemplary platform via gateway 520. At the user terminal, the identifier for the asset can be encrypted. The encrypted asset identifier and the one or more user- specified conditions can be sent via the gateway 520 to the in-memory cache 530. The inmemory cache 530 may include a matching engine that can match trade requests in the inmemory cache based on user-specified conditions. As discussed above, the asset identifier is encrypted with a user-specific session key. The encrypted asset identifier is decrypted by the platform before it is passed into the in-memory cache (based on the session key). The decrypted asset identifier is not stored anywhere, nor visible in any logs accessible by employees of the platform to prevent leakage of matched trading requests. [0072] Further, the in-memory cache can include an open data port (e.g., port 6379) for receiving the encrypted asset identifier and the user-specified conditions and optionally for updating or canceling trade requests. But, the other data ports of the in-memory cache (e.g., SSH (port 22), HTTPS (port 443), and HTTP (port 80)) are closed such that data in the in-memory cache cannot be retrieved (even by employees of the transaction platform) or analyzed. Once a match is made between two trade requests, the matched trade requests may be sent to be stored in one or more databases 540 in a more persistent manner. The one or more databases may include a database for storing matches and a credibility blockchain for storing the credibility ratings of the users and/or brokers. In some examples, only one data port (e.g., 1521) is open on the database to limit access of the data. As shown in the figure, one or more backend users 554 may access the platform 500 via a VPN connection. In one or more embodiments, the system may be in communication with a search service 552.

[0073] In some examples, if an issue is identified and the platform needs to troubleshoot the in-memory cache, the only possible way is for the system to wipe all content from the inmemory cache and turning off/on the gateway.

[0074] In some examples, the one or more databases 540 can be encrypted, but the stored matches within the database are not stored in an encrypted state. For added security of the data, the system can use the Oracle provided Transparent Data Encryption (TDE). TDE transparently encrypts data at rest in Oracle Databases. It stops unauthorized attempts from the operating system to access database data stored in files, without impacting how applications access the data using SQL. In some examples, the system uses the default encryption cyphers for TDE, AES 192 for column encryption and AES 128 for tablespace encryption.

[0075] The credibility blockchain captures each user’s credibility score at different time points. Each blockchain entry can specify what action and/or algorithm increased or decreased their credibility score at a particular time point. A user’s overall credibility score is based on aggregation of all of their blockchain entries over time.

[0076] FIG. 6 illustrates an exemplary process flow for securely matching a trade request between users. Reference to FIGS. 7A-7M are used to illustrate this process. This process can be performed, for example, using one or more electronic devices implementing a software platform. In some examples, this process is performed using a client-server system, and the blocks of this process are divided up in any manner between the server and a client device. In other examples, the blocks of this process are divided up between the server and multiple client devices. Thus, while portions of this process are described herein as being performed by particular devices of a client-server system, it will be appreciated that this process is not so limited. In other examples, this process is performed using only a client device or only multiple client devices. In this process, some blocks are, optionally, combined, the order of some blocks is, optionally, changed, and some blocks are, optionally, omitted. In some examples, additional steps may be performed in combination with this process. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

[0077] At block 611, a user may log-in to the platform 600 via a user application 610. In some embodiments, platform 600 may correspond to platform 500 described above. In some embodiments, the user application 610 may access the platform via the gateway (e.g., gateway 520). For instance, the gateway may prompt the user to enter their user credentials. If the user credentials are valid, the platform can authenticate the user and proceed to block 621.

[0078] At block 621, the platform can generate user tokens and a session key. As shown in the figure, for example, the session key may be XXX-SSS-FDF-121. The platform 600 can send the generated user tokens to the user application 610. At block 613, the user application 610 can store the session key.

[0079] At block 615, the user application 610 may receive a request for available assets (e.g., stocks) from the user. FIG. 7A illustrates an exemplary user interface 700 A in accordance with embodiments of the present disclosure. As shown in the figure, the user interface 700A may include a user’s credibility rating 702A, a user identifier 704A, and a search user affordance 706A. The user identifier 704A may show which user is currently logged in to the platform. The user credibility rating 702A may indicate the credibility rating of the user. The search user affordance 706A may be allow a user to input a text entry to search for one or more stocks or securities (e.g., underliers). 1 [0080] At block 623, the platform may receive the user request for available assets from the user and return a list of assets with corresponding asset identifiers. The asset identifiers may be encrypted using the session key. For instance, each asset may be associated with an encrypted asset identifier and a asset name, e.g. {Stock ID = XSAD-SSS, Stock Name = 1701. T}; and {ID = XSAD-SSS, Name = 1801.T} . The platform 600 may send the list of requested assets to the user application 610, which can decrypt the data to present to the user.

[0081] In some examples, no basic HTTP communication is allowed and all HTTP traffic is automatically redirected to HTTPS using AWS Load Balancers. In some examples, for the HTTPS protocols and encryption cypher support, the system may use the recommended AWS security policy "ELBSecurityPolicy-2016-08" for secure data transfer.

[0082] At block 617, the user application 610 can store the assets listing with a session unique identifier. A user can create a trade request based on one or more of the assets provided in the assets listing. FIG. 7B illustrates an exemplary user interface 700B that can present an exemplary trade request. As shown in the figure, the user interface can include the user identifier 704B, the user credibility rating 702B, a list of trade requests 708B created by the user, a trade request 710B, and a status of the trade request 712B. As shown in the figure, the trade request can include a plurality of trade request criteria. The trade request criteria can include, but is not limited, to a name of a asset, a requested quantity, a cost of the asset (in one or more currencies), a requested action (e.g., sell or buy), a cost, a transaction type, price conditions, advertising preferences, and path preferences.

[0083] The user can adjust one or more trade request criteria via the user interface. For instance, FIG. 7C illustrates an exemplary user interface 700C, where the user can specify a quantity (e.g., number of shares) for the selected asset. In some embodiments, the user can select the “quantity” icon and the user interface may present a user affordance to allow a user to enter a desired asset quantity. FIG. 7D illustrates an exemplary user interface 700D, where the user can specify one or more price conditions for the selected asset. These price conditions may automatically activate the trade request or cancel the trade request when the price condition is met. For instance, the user can select whether to activate an advertising trigger, a cancel trigger, and an index relative cancel. An advertising trigger can specify a price condition that an asset must satisfy (i.e. if asset X is above price level Y)) to convert the status of an IOI from status “pending” to status “sent.” A cancel trigger can specify a price condition (e.g., if asset X is above price level Y) that, if satisfied, converts the status of an IOI from “sent” to “cancelled.” An index relative cancel can specify a price condition (e.g., if performance of asset X > performance of index Z) that, if satisfied, converts the status of an IOI from “sent” to “cancelled.” While selecting the price conditions, the user interface 700D can present a trading range of the selected asset that includes a max price range and a minimum price range.

[0084] FIG. 7E illustrates an exemplary user interface 700E, where the user can specify one or more advertising preferences for the selected asset. As shown in the figure, the advertising preferences can include a contra user credibility filter, a duration, a minimum quantity percentage, a quantity decay, and a transaction type. The minimum quantity percentage can specify the percentage of the original IOI quantity that a contra IOI must be greater than or equal to, in order for a match to occur (e.g., if original quantity is 100,000 shares and minimum quantity percentage is 50,000 shares, a contra IOI must have at least 50,000 shares to be eligible as a match). The quantity decay depletes the quantity of an IOI over time (e.g., if there were 100,000 shares on an IOI with duration of 60 minutes with decay turned on, there would be only 50,000 shares on the IOI after 30 minutes).

[0085] In order for a trade request to match with another trade request from a contra user, each of the specified advertising preferences need to be satisfied. The credibility filter corresponds to the minimum credibility rating of the other user involved in the trade request. The duration corresponds to a time by which the trade request should be filled, e.g., if the length of time from the user submitting the trade request exceeds the specified duration, the trade request will automatically be canceled.

[0086] FIG. 7F illustrates an exemplary user interface 700F, where the user can specify one or more path preferences for the selected asset. As shown in the figure, the user can rank one or more brokers to perform the trade request once the trade request is accepted by a second user. In some embodiments, the user may set each of the brokers to an equal rank, e.g., if the user is agnostic as to which broker to user. In some embodiments, each broker may be associated with a credibility ranking. The user may rely on the broker’s credibility rating to rank the brokers. In some embodiments, a user may filter one or more brokers based on a credibility rating. For instance, a user may specify preferences that brokers should have a rating of 3 out of five or higher. In such embodiments, any brokers with a rating below 3 will not be available for the user to rank or select. The type of rating is exemplary and other ratings types (e.g., x out of five; x out of ten; A, B, C, D, F; etc.) may be used without departing from the scope of this disclosure.

[0087] At block 618, the user may transmit the trade request with an encrypted asset identifier (e.g., “XSAD-SSS”). Referring briefly to FIG. 7F, the user may select the “send” user affordance below the trade request 71 OF, once the user has specified the desired user conditions. FIG. 7G illustrates an exemplary user interface 700G, where the user has sent the trade request. For instance, as shown in the figure the trade status 812G of the trade request 810G is “sent.” Once the status of a trade request is “sent,” a user may select a user affordance to cancel, pause, or update the trade request.

[0088] The platform 600 can receive the trade request with the encrypted asset identifier (e.g., “XSAD-SSS” in FIG. 6). Referring briefly to FIG. 5, the platform may receive the trade request from the user via the gateway 520. Because of the encryption, the platform (including the employees of the platform) is unable to identify the underlying asset associated with the trade requests and thus cannot use such information to manipulate the market.

[0089] At block 625, the platform 600 can decrypt the encrypted asset identifier. The decrypted asset identifier is not stored or logged anywhere after decryption such that the platform (or its employees) cannot identify the asset. After decryption, the asset identifier can be passed from the gateway to a matching engine of the in-memory cache 530. Once the decrypted asset identifier is provided to the in-memory cache 530, it cannot be retrieved from the in-memory cache 530, thus preventing the platform 600 and other parties from being able to determine the identity of the asset in the trade request and thus preventing market manipulation.

[0090] At block 627, the platform 600 can match the trade request with one or more preexisting trade requests. The in-memory cache 530 may contain other trade requests previously received from other users that have not been matched. The in-memory cache 530 may include a matching engine to facilitate matches between the trade requests. In some examples, in the inmemory cache 530, the trade requests are not recorded in persistent storage. [0091] Trade requests can be grouped by asset within the matching engine such that the trade requests related to the same asset (e.g., the same stock) are in the same group and can be matched within that group. In some embodiments, the matching engine may organize the trade requests by Stock Name (e.g., {Stock ID = XSAD-SSS, Stock Name = 1701. T}. When the matching engine receives a trade request, it determines whether there is a pre-existing trade request in the same asset group that satisfies each of the user-specified conditions (e.g., asset, price conditions, quantity, advertising preferences, path preferences, etc.). If so, the matching engine 532 may match the two trade requests.

[0092] Once the matching engine 532 determines a match between two trade requests (block 625), the matched trade requests may be sent to the one or more databases 540 to be stored in a persistent memory. In this manner, bad actors attempting to intercept and/or seeking access to the received trade requests will be unable to determine the underlying asset of the trade request, e.g., because the identity of the asset is encrypted in the in-memory cache 530.

[0093] In some embodiments, the hardware associated with the in-memory cache may include two ports: a first port to receive trade requests, and a second port to output trade requests that have been matched. In this manner, the hardware of the system adds an additional layer of protection by reducing the ability of bad actors to access data in the in-memory cache. In some embodiments, the in-memory cache 530 is not configured to receive queries. Accordingly, the in-memory cache is unable to receive a query regarding how many trade requests are associated with a particular Stock Name.

[0094] At block 619, the user application 610 may receive and present a notification to the user that a match was made. Both users (e.g., buyer and seller) involved in the transaction receive a notification that a match was made. FIG. 7H illustrates an exemplary user interface 700H, for a first user (e.g., buyer) that includes a notification that the trade request was matched. As shown in the figure, the notification can include an indication of the trade request direction (e.g., buy), a quantity, a transaction type, and a minimum quantity. In some embodiments, the user will have an allotted time (e.g, 30 seconds) to accept the trade after receiving the notification. If the user application 610 does not receive a selection by the allotted time, the trade request can be automatically cancelled. The length of the allotted time is not intended to limit the scope of the disclosure. FIG. 71 illustrates an exemplary user interface 7001 for the second user (e.g., seller) involved in the matched trade request. As shown in the figure, the notification can include an indication of the trade request direction (e.g., sell), a quantity, a transaction type, and a minimum quantity. The second user may have the same amount of allotted time to accept the trade request. While the first user in this example, is referred to as the buyer and the second user is referred to as the seller, these designations of the first user and second user are not intended to limit the scope of the disclosure.

[0095] At block 629, the platform 600 can receive an indication of whether the match was accepted by the users associated with the matched trade requests.

[0096] FIG. 7 J illustrates an exemplary user interface 700 J, of the second user second (e.g., seller), where the second user has declined the trade request. As shown in the figure, the user interface 700J may display a notification 726J indicating that the match (e.g., connection) was declined. When a user declines a match, the trade request from the declining user can be cancelled. The user interface 700J also shows an updated status 712J that the trade request is cancelled. If the first user (e.g., buyer) had cancelled the trade request a similar notification would be displayed. In some embodiments, declining a trade match may impact a credibility rating of the user. For instance, declining a trade request may decrease a user’s credibility rating.

[0097] FIG. 7K illustrates an exemplary user interface 700K, of the first user (e.g., buyer) where the second user has declined the trade request. As shown in the figure, the user interface 700K may display a notification 726K indicating that the match (e.g., connection) was declined by the other user (e.g., contra or second user). When the other user declines a match, the trade request from the non-declining user will remain active. The user interface 700K reflects this by showing that the status 812K of the first user (e.g., buyer) remains “sent.”

[0098] FIG. 7L illustrates an exemplary user interface 700L, of the second user (e.g., seller) when both users have accepted the match. As shown in the figure, the notification 730L includes a summary of the trade criteria including the trade direction (e.g., sell), trade quantity, transaction type, price, connection time, password, and broker. As shown in the figure, each user is provided with a password 732L to be provided to the specified broker to complete the transaction. [0099] FIG. 7M illustrates an exemplary user interface 700M, of the first user (e.g., buyer) when both users have accepted the match. As shown in the figure, the notification 734M includes a summary of the trade criteria including the trade direction (e.g., sell), trade quantity, transaction type, price, connection time, password, and broker. As shown in the figure, each user is provided with a password AIFB1669D7 to be provided to the specified broker to complete the transaction. In some embodiments, as shown in FIGS. 7L and 7M, unique passwords are provided to each user.

[0100] FIG. 8A illustrates an exemplary process for completing a transaction via a broker. This process can be performed, for example, using one or more electronic devices implementing a software platform. In some examples, this process is performed using a client-server system, and the blocks of this process are divided up in any manner between the server and a client device. In other examples, the blocks of this process are divided up between the server and multiple client devices. Thus, while portions of this process are described herein as being performed by particular devices of a client-server system, it will be appreciated that this process is not so limited. In other examples, this process is performed using only a client device or only multiple client devices. In this process, some blocks are, optionally, combined, the order of some blocks is, optionally, changed, and some blocks are, optionally, omitted. In some examples, additional steps may be performed in combination with this process. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

[0101] At block 881, a broker may log-in to the platform 800A via a broker application 880. In some embodiments, platform 800A may correspond to platform 500 described above. In some embodiments, the broker application 880 may access the platform via the gateway e.g., gateway 520). For instance, the gateway may prompt the broker to enter their broker credentials. If the broker credentials are valid, the platform can authenticate the broker and proceed to block 521. FIG. 8B illustrates an exemplary user interface 850B. As shown in the figure, the user interface 850B can include a login identifier of the broker (e.g, “Broker 0”) to the platform as well as a summary screen that includes a list of transactions associated with Broker 0. [0102] At block 802, the platform 800A may receive an indication that a match was made between two trade requests (e.g., as described with respect to FIG. 6). The match will be associated with a broker selected based on the user-specified conditions of the trade requests. At block 882, the broker application 880 associated with the broker selected based on the user- specified conditions of the trade requests can receive the matched trade request.

[0103] Referring briefly to FIGS. 7L and 7M, the matched trade request specifies Broker 0 has been selected to execute the trade transaction. FIG. 8C illustrates an exemplary user interface 850C for Broker 0. As shown in the figure, Broker 0 may receive a notification that they have been selected to execute a trade on behalf of a first user (e.g., buyer) and a second user (e.g., seller). In some embodiments, brokers via the broker application can receive matched trade requests, but cannot generate trade requests. Rather, the broker receives trade requests once the trade requests are matched via the platform’s matching engine. Restricting a broker’s ability to generate trade requests may also reduce the likelihood of bad actors gathering information or improperly executing trade transactions. FIG. 8D illustrates an exemplary user interface 850C for Broker 0 and shows the trade criteria associated with the trade transaction. As shown in the figure, the trade criteria can include, but is not limited to: the security, the quantity, the price, the type, a buy password, a buy status, a sell password, a sell status, and a time stamp. This trade criteria may correspond to the trade criteria displayed in user interfaces 700L and 700M. As shown in the figure, the buy status and the sell status for is pending.

[0104] At block 804 the platform 800A may receive the first user password from the first user. For instance, the first user may enter the password into a user interface (e.g. via user application 610). At block 883, the broker application 880 can receive a first user password from the platform 800A. For instance, if the first user password is associated with the buyer, once the broker application receives the buyer password, the broker application 880 can confirm receipt of the first user password. For instance, the broker, via the broker application 880, can change the buy status from “pending” to “received” at block 884. FIG. 8E illustrates an exemplary broker interface, where the broker employee has updated the buy status from “pending” to “received.” Changing the buy status confirms that the first user (e.g., buyer) provided the password. In some embodiments, the credibility rating of the first user will increase once the first user (e.g., buyer) provides their buyer password. [0105] At block 806 the platform 800A may receive the second user password from the second user. For instance, the second user may enter their password into a user interface (e.g. via user application 610). At block 885, the broker application 880 can receive a first user password from the platform 800A. If the second user password is associated with the seller, once the broker application receives the seller password, the broker application 880 can confirm receipt of the second user password. For instance, broker can change, via the broker application 880, the sell status from “pending” to “received” at block 886. FIG. 8E illustrates an exemplary user interface 850E, where the broker employee has updated the buy status from “pending” to “received.” Changing the buy status confirms that the first user (e.g., buyer) provided the password. In some embodiments, the credibility rating of the first user will increase once the first user (e.g., buyer) provides their buyer password.

[0106] At block 887, after receipt of both the buyer and seller passwords are confirmed, the broker application can execute the trade. FIG. 8F illustrates an exemplary user interface 850F, where the broker application has confirmed that the buyer and seller passwords have been confirmed and that the trade transaction is ready for execution.

[0107] When specifying the conditions for a trade request, a user can specify the path preference or broker preference for the trade. FIG. 8G illustrates an exemplary diagram illustrating how a broker is selected based on the user-specified path preferences. At 81 G, a user can specify a path preference, e.g., {rank 1, rank 2, rank 3}. For instance, an initial list of brokers may be specified as {Broker A, Broker B, Broker C}. The user may determine Broker B is the least desirable and reorder the list of brokers as {Broker A, Broker C, Broker B}. At 82G, the user may activate or de-activate brokers. For instance, as shown, a user can deactivate Broker B and/or deactivate Brokers B and C. Each rank may be associated with an allocated number of points. As a non-limiting example, rank 1 may be associated with a first number of points, e.g, six points; rank 2 may be associated with a second number of points, e.g, four points; and rank 3 may be associated with third number of points, e.g, one point. This allocation of points is exemplary and is not intended to be limiting. A different allocation of points may be used and/or an algorithm may be used to determine an allocation of points. [0108] Rows 84G-86G illustrate exemplary broker selections based on the path preferences of a first user and a second user. At row 84G, Broker A is selected to execute the transaction, when the first user has a path preference of {Broker A, Broker B, Broker C} and the second user has a path preference of {Broker A, Broker C, Broker B}. At row 85G, Broker B is selected to execute the transaction, when the first user has a path preference of {Broker A, Broker B, Broker C} and the second user has a path preference of {deactivated-Broker A, Broker C, Broker B}. At row 85G, Broker B is selected to execute the transaction, when the first user has a path preference of {Broker A, Broker B, deactivated-Broker C} and the second user has a path preference of {deactivated-Broker A, Broker C, Broker B}.

[0109] FIGS. 8H-8J illustrate exemplary user interfaces for selecting a broker. FIG. 8H illustrates a user interface 800H showing the second user’s (e.g., seller) path preference as {Broker 0, Broker 1, Broker 2, Broker 3}. FIG. 81 illustrates a user interface 800H showing the first user’s (e.g., buyer’s) path preference as {Broker 3, Broker 1, Broker 2, Broker 0}. FIG. 8J illustrates that a match between the first user and the second user results in the selection of Broker 1. When a broker is selected, the selected Broker (e.g., Broker 1), will be notified of the match between the trade requests; the unselected Brokers will not receive a notification that a match between trade requests of the first and second users was made.

[0110] In one or more embodiments, the platform can determine and maintain a credibility rating associated with each user and each broker. Actions taken by the user and the broker may be monitored and used by the platform to update a user’s credibility rating. For instance, as discussed above, a user accepting a trade request match (e.g., user interfaces 700L and 700M) may increase the user’s credibility rating; while a user declining a trade request match (e.g., user interfaces 700L and 700M) may decrease the user’s credibility rating. Actions that may impact a user’s credibility rating may include, but is not limited to uploading a trade request, accepting a trade request, accepting a matched buy despite a price increase, accepting a patched sell trade request despite a price increase, declining a trade request, failing to respond to a match (e.g., timeout of allotted time to accept a match), canceling an unmatched trade request, declining a matched buy trade request despite a price decrease, declining a matched sell trade request despite a price increase, failing to send an order to broker after accepting a match, security price moves lower after declining a matched buy trade request, security price moves higher after declining a matched sell trade request, unmatched trade requests are canceled within five minutes of upload. In one or more embodiments, the credibility rating associated with a user may be determined by the platform using an algorithm and/or machine learning. The credibility rating may be stored in blockchain in the one or more databases 540.

[0111] FIGS. 9A-9C illustrates exemplary user interfaces that illustrate how a user’s credibility score can impact an opportunity to match trade requests between users. FIG. 9A illustrates an exemplary user interface for a second user 904A (e.g., seller). As shown in the figure, the second user 904A has a credibility rating 902A. The second user 904A has specified under advertising preferences that in order for a match to occur, the buyer of the matched trade request should have a credibility rating of at least two out of five. FIG. 9B illustrates an exemplary user interface for a first user 904B (e.g., seller). As shown in the figure, the first user 904B has a credibility rating 902B. The first user 904B has specified via the credibility filter 918B a match can occur when the seller of the matched trade request has a credibility rating of at least four out of five. Because the second user (e.g., seller) has a credibility rating of three out of five, a match will not occur between the first and second user because the advertising preferences specified by the first user are not satisfied.

[0112] As shown in FIG. 9C, the first user 904C has updated the credibility filter to three out of five. Because the second user has a credibility rating of three out of five and the other user- specified trade conditions are met, a match can be made between the trade requests of the first and second users, as illustrated in user interface 900D of FIG. 9D.

[0113] FIG. 10 illustrates an exemplary process 1000 for matching a trade request of a user according to embodiments of the present disclosure. Process 1000 can be performed, for example, using one or more electronic devices implementing a software platform. In some examples, process 1000 is performed using a client-server system, and the blocks of process 1000 are divided up in any manner between the server and a client device. In other examples, the blocks of process 1000 are divided up between the server and multiple client devices. Thus, while portions of process 1000 are described herein as being performed by particular devices of a client-server system, it will be appreciated that process 100 is not so limited. In other examples, process 1000 is performed using only a client device or only multiple client devices. In process 1000, some blocks are, optionally, combined, the order of some blocks is, optionally, changed, and some blocks are, optionally, omitted. In some examples, additional steps may be performed in combination with the process 1000. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

[0114] At block 1002, the platform can receive a new trade request (e.g., indication of interest (IOI)). For instance, the platform may receive user specified conditions to be executed as a trade transaction (e.g., as described with respect to FIG. 6). At block 1004, the platform can determine whether the trade request is associated with a price trigger. If the trade request is associated with a price trigger, the platform may determine whether the price trigger is satisfied at block 1006. If the price trigger is not satisfied, the platform can wait for a predetermined time interval (e.g., five minutes), at block 1008. The length of the time interval is not intended to be limiting and any time interval, e.g, on the order of seconds, minutes, hours etc., may be used without departing from the scope of this disclosure. In some embodiments, the platform may additionally batch process the trade requests to consolidate price queries on the same stocks and/or securities for the price trigger analysis. This batch processing may improve the speed and efficiency of process 1000 and lead to an improvement of performance of the device executing process 1000.

[0115] Following the predetermined time interval, at block 1010, the platform can determine whether the trade request has timed out, e.g, based on a user specified condition for how long the trade request should be active. If the trade request is timed out, the platform will cancel the trade request at block 1032. In one or more examples, when a trade request is canceled, the trade request status displayed to the user may be changed to “dead.” In some embodiments, the reasons for the cancellation or “death” of the trade request may be presented to the user via the user interface. If the trade request is not timed out, the platform will return to block 1006 to determine whether the price trigger is satisfied. If the price trigger is satisfied, the platform will move to block 1012, where the trade request is analyzed by the matching engine, which resides in the in-memory cache as described above.

[0116] At block 1014, other trade requests residing in the in-memory cache may be compared to the trade request. At block 1016, the matching engine may run background processes to evict stale pre-existing trade requests, determine whether a halted stock or security should force a cancellation of associated trade requests, determine whether a specific user’s trade requests should be canceled, etc. With reference to FIG. 10, a stale IOI is an IOI that has run out of time allocated by the user via the duration selected at creation (e.g., an IOI with duration of 60 minutes that remains unmatched or cancelled 61 minutes after being sent). These background processes may be performed to ensure that valid and active trade requests are available for analysis by the matching engine. That is, the matching engine may compare the trade criteria of the new incoming trade request to the trade criteria of pre-existing trade requests to determine whether to make a match. At block 1020, the platform can determine whether a match (e.g., a second trade request with trade criteria that satisfies the trade criteria of the trade request) was found. If no match was found, the platform may return to block 1020.

[0117] If a match was found, the platform can update the trade request status to “matched,” at block 1022. At block 1024, the platform can further determine whether the trade request includes a knock-out condition. In one or more embodiments, knock-out conditions may include, but are not limited to: price limit, performance related to index performance, etc. If the trade request associated is knocked-out at block 1026, the trade request with the knock-out condition will be canceled at block 1032. If the trade request is not knocked-out, the platform will determine whether the trade request has an index relative knock-out condition, at block 1028. If there is an index-relative knock-out condition, the platform will knock out the trade request with the knock-out condition at block 1030 and cancel the trade request at 1032. If there is no index relative knock-out condition at block 1028 or the trade request is not knocked-out at block 1030, the platform may notify the user that a match was match was made at block 1034.

[0118] At block 1038, the platform may receive an indication of whether a match was accepted. For instance, once the user is notified of a match, the user may have a predetermined interval of time to decide wither to accept or decline the match, as discussed above with respect to FIGS. 7J -7M. If the match is declined, the trade request associated with the can be cancelled at block 1032. If the match is accepted by the user, the platform can determine, at block 1040, whether the contra match was accepted by the second user associated with the second trade request involved in the match. If the contra match was not accepted by the second user, the platform can cancel the contra trade request at block 1042. The trade request may then be sent back to the matching engine to be matched with another trade request.

[0119] If the contra match was accepted, the trade request can be removed from the matching engine at block 1044. At block 1046, the platform can determine whether the trade request is associated with a residual quantity. For instance, if a first trade request includes an offer to buy five shares at a price of $100 and a second trade request includes a request to sell three shares at a price of $100, the platform may match the first and second trade requests. However, this match results in the first trade request having a residual of an offer to buy two shares at $100. If there is no residual, at block 1050, the platform can send the user the notification that the match has occurred and provide the broker and password information for the user to complete the trade. Once the trade is completed (e.g, the broker receives both passwords from the first and second users), at block 1052, the platform can change the status of the trade request from “matched” to “completed.” In instances where there is a residual, the platform can determine at block 1048, whether the residual quantity of shares is greater than a minimum quantity. The minimum quantity may be specified by the user or predetermined the platform. If the residual quantity is not greater than the minimum quantity, the platform can proceed to block 1050. If the residual quantity is greater than the minimum quantity, the platform can proceed to block 1054 where the platform can prompt the user to approve a residual trade request and send the user a notification that the match has occurred and provide the broker and password information for the user to complete the trade with respect to the matched shares. The user can approve the residual trade request at block 1056. In some embodiments, the new trade request may include an updated quantity but may otherwise have the same trade criteria as the original trade request. In some embodiments, the user can further update the new trade request to specify new trade criteria, e.g, a new path preference, new price triggers, etc. At block 1058, the platform can create a new trade request based on the user’s newly accepted trade request. The new trade request can then be input into the matching engine at block 1012 for a match.

[0120] FIG. 11 illustrates an exemplary process 1100 according to embodiments of the present disclosure. Process 1100 can be performed, for example, using one or more electronic devices implementing a software platform. In some examples, process 1100 is performed using a client-server system, and the blocks of process 1100 are divided up in any manner between the server and a client device. In other examples, the blocks of process 1100 are divided up between the server and multiple client devices. Thus, while portions of process 1100 are described herein as being performed by particular devices of a client-server system, it will be appreciated that process 1100 is not so limited. In other examples, process 1100 is performed using only a client device or only multiple client devices. In process 1100, some blocks are, optionally, combined, the order of some blocks is, optionally, changed, and some blocks are, optionally, omitted. In some examples, additional steps may be performed in combination with the process 1100. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

[0121] An exemplary process 1100 for facilitating secure transactions via encryption comprises: at block 1102, receiving, from a first user, one or more user-specified conditions for performing a secure transaction for an asset, wherein the asset is associated with an asset identifier; at block 1104, encrypting the asset identifier associated with the asset to obtain an encrypted identifier; at block 1106, constructing a new user request comprising the encrypted identifier and data associated with the one or more user-specified conditions; at block 1108, transmitting the new user request to a transaction platform; at block 1110, inputting, by the transaction platform, the new user request into an in-memory cache via an open data port, wherein the in-memory cache comprises the open data port and a plurality of closed data ports to prevent retrieval of the asset identifier from the in-memory cache, and wherein inputting the new user request comprises decrypting the encrypted identifier to obtain the asset identifier; at block 1112, without the transaction platform identifying the asset, comparing, at the in-memory cache, the new user request to a pre-existing user request associated with a second user; and at block 1114, in accordance with a determination that the asset identifier matches the pre-existing user request, and further in accordance with a determination that the pre-existing user request satisfies the one or more user-specified conditions of the new user request: storing the transaction to a persistent database; and transmitting a first confirmation request to a first electronic device of the first user and a second confirmation request to a second electronic device of the second user.

[0122] The scope of this disclosure encompasses all changes, substitutions, variations, alterations, and modifications to the example embodiments described or illustrated herein that a person having ordinary skill in the art would comprehend. The scope of this disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates respective embodiments herein as including particular components, elements, feature, functions, operations, or steps, any of these embodiments may include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere herein that a person having ordinary skill in the art would comprehend. Furthermore, any reference herein to an apparatus or system or a component of an apparatus or system being adapted to, arranged to, capable of, configured to, enabled to, operable to, or operative to perform a particular function encompasses that apparatus, system, component, whether or not it or that particular function is activated, turned on, or unlocked, as long as that apparatus, system, or component is so adapted, arranged, capable, configured, enabled, operable, or operative. Additionally, although this disclosure describes or illustrates particular embodiments as providing particular advantages, particular embodiments may provide none, some, or all of these advantages.

31

Claims

1. A method for facilitating secure transactions via encryption, the method comprising: receiving, from a first user, one or more user-specified conditions for performing a secure transaction for an asset, wherein the asset is associated with an asset identifier; encrypting the asset identifier associated with the asset to obtain an encrypted identifier; constructing a new user request comprising the encrypted identifier and data associated with the one or more user-specified conditions; transmitting the new user request to a transaction platform; inputting, by the transaction platform, the new user request into an in-memory cache via an open data port, wherein the in-memory cache comprises the open data port and a plurality of closed data ports to prevent retrieval of the asset identifier from the in-memory cache, and wherein inputting the new user request comprises decrypting the encrypted identifier to obtain the asset identifier; without the transaction platform identifying the asset, comparing, at the in-memory cache, the new user request to a pre-existing user request associated with a second user; and in accordance with a determination that the asset identifier matches the pre-existing user request, and further in accordance with a determination that the pre-existing user request satisfies the one or more user-specified conditions of the new user request: storing the transaction to a persistent database; and transmitting a first confirmation request to a first electronic device of the first user and a second confirmation request to a second electronic device of the second user.

2. The method of claim 1, further comprising: receiving one or more user credentials from the first user; in accordance with a determination that the one or more user credentials are valid, generating a session key for the first user; and transmitting the session key to the first electronic device of the first user, wherein the identifier is encrypted based on the session key.

3. The method of claim 1 or claim 2, wherein the one or more user-specified conditions comprises: a price condition, a quantity, a user identifier, a credibility score associated with the first user, a time condition, a transaction type, or any combination thereof.

4. The method of any one of the preceding claims, wherein the one or more user-specified conditions comprises: one or more brokers, a preference ranking related to the one or more brokers, a credibility score requirement, or any combination thereof.

5. The method of claim 4, further comprising: determining whether the pre-existing user request satisfies the one or more user-specified conditions of the new user request at least partially by determining whether the pre-existing user request and the new user request share a common preferred broker.

6. The method of any one of the preceding claims, wherein the one or more user-specified conditions comprises: a credibility requirement for the second user.

7. The method of any one of the preceding claims, wherein the one or more user-specified conditions comprise one or more conditions for cancelling the new user request.

8. The method of claim 7, further comprising: determining whether the one or more conditions for cancelling the new user request are met; and if the one or more conditions for canceling the new user request are met: foregoing sending the first confirmation request and the second confirmation request.

9. The method of claim 7 or claim 8, wherein the one or more conditions for canceling the new user request comprise a price condition for the asset, a performance condition for the asset, or any combination thereof.

10. The method of any one of the preceding claims, further comprising: receiving a rejection by the first user in response to the first confirmation request; and reducing a credibility score associated with the first user based on the rejection.

11. The method of claim 10, further comprising: generating a new blockchain entry based on the reduction of the credibility score associated with the first user; adding the new blockchain entry to a blockchain associated with the credibility history of the first user.

12. The method of claim 10, further comprising canceling the new user request in accordance with receiving the rejection.

13. The method of any one of the preceding claims, further comprising: receiving a first acceptance by the first user in response to the first confirmation request; receiving a second acceptance by the second user in response to the second confirmation request; and transmitting a first password for the transaction to the first user and a second password for the transaction to the second user.

14. The method of claim 13, further comprising: presenting, via a remote terminal of a broker, the transaction between the first user and the second user; receiving the first password from the first user; receiving, via the remote terminal, confirmation that the first password was accepted; receiving the second password of the second user; receiving, via the remote terminal, confirmation that the second password was accepted; and in accordance with receipt of the confirmation that the first password was accepted and confirmation that the second password was accepted, executing the transaction based on the one or more user-specified conditions of the new user request.

15. The method of claim 14, further comprising increasing a credibility score associated with the first user based on the confirmation that the first password was accepted.

16. The method of any one of the preceding claims, further comprising: updating a credibility score associated with the first user based on: a first price of the asset before injecting the new user request; a second price of the asset after the first confirmation request is transmitted; a third price of the asset after the first confirmation request is responded to; or any combination thereof.

17. The method of any one of the preceding claims, wherein the asset comprises a stock.

18. The method of claim 17, wherein the second user is a trader of the stock.

19. A system for facilitating secure transactions via encryption, comprising: one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for: receiving, from a first user, one or more user-specified conditions for performing a secure transaction for an asset, wherein the asset is associated with an asset identifier; encrypting the asset identifier associated with the asset to obtain an encrypted identifier; constructing a new user request comprising the encrypted identifier and data associated with the one or more user-specified conditions; transmitting the new user request to a transaction platform; inputting, by the transaction platform, the new user request into an in-memory cache via an open data port, wherein the in-memory cache comprises the open data port and a plurality of closed data ports to prevent retrieval of the asset identifier from the in-memory cache, and wherein inputting the new user request comprises decrypting the encrypted identifier to obtain the asset identifier; without the transaction platform identifying the asset, comparing, at the in-memory cache, the new user request to a pre-existing user request associated with a second user; and in accordance with a determination that the asset identifier matches the pre-existing user request, and further in accordance with a determination that the pre-existing user request satisfies the one or more user-specified conditions of the new user request: storing the transaction to a persistent database; and transmitting a first confirmation request to a first electronic device of the first user and a second confirmation request to a second electronic device of the second user.

20. A non-transitory computer-readable storage medium storing one or more programs for facilitating secure transactions via encryption, the one or more programs comprising instructions, which when executed by one or more processors of an electronic device having a display, cause the electronic device to perform: receiving, from a first user, one or more user-specified conditions for performing a secure transaction for an asset, wherein the asset is associated with an asset identifier; encrypting the asset identifier associated with the asset to obtain an encrypted identifier; constructing a new user request comprising the encrypted identifier and data associated with the one or more user-specified conditions; transmitting the new user request to a transaction platform; inputting, by the transaction platform, the new user request into an in-memory cache via an open data port, wherein the in-memory cache comprises the open data port and a plurality of closed data ports to prevent retrieval of the asset identifier from the in-memory cache, and wherein inputting the new user request comprises decrypting the encrypted identifier to obtain the asset identifier; without the transaction platform identifying the asset, comparing, at the in-memory cache, the new user request to a pre-existing user request associated with a second user; and in accordance with a determination that the asset identifier matches the pre-existing user request, and further in accordance with a determination that the pre-existing user request satisfies the one or more user-specified conditions of the new user request: storing the transaction to a persistent database; and transmitting a first confirmation request to a first electronic device of the first user and a second confirmation request to a second electronic device of the second user.