US20190325515A1 - Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server - Google Patents

Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server Download PDF

Info

Publication number
US20190325515A1
US20190325515A1 US15/727,628 US201715727628A US2019325515A1 US 20190325515 A1 US20190325515 A1 US 20190325515A1 US 201715727628 A US201715727628 A US 201715727628A US 2019325515 A1 US2019325515 A1 US 2019325515A1
Authority
US
United States
Prior art keywords
cryptocurrency
data
exchange
filtered
unique
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US15/727,628
Inventor
David Marc Weisberger
Ian Joseph Weisberger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Coinroutes Inc
Original Assignee
Coinroutes Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Coinroutes Inc filed Critical Coinroutes Inc
Priority to US15/727,628 priority Critical patent/US20190325515A1/en
Priority to US16/754,059 priority patent/US11580600B2/en
Priority to PCT/US2018/064111 priority patent/WO2019071277A1/en
Priority to EP18864471.0A priority patent/EP3692486A4/en
Priority to PCT/US2018/064115 priority patent/WO2019071278A1/en
Priority to EP18864655.8A priority patent/EP3692491A4/en
Assigned to COINROUTES INC. reassignment COINROUTES INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WEISBERGER, David Marc, WEISBERGER, Ian Joseph
Publication of US20190325515A1 publication Critical patent/US20190325515A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0658Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed locally
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06Asset management; Financial planning or analysis

Definitions

  • the Crypto-Currency 1 market is served by multiple exchanges, many of which are inaccessible to investors in various jurisdictions or, at a particular moment invalid for a client to utilize due to lack of funding or available cryptocurrencies in the appropriate wallet.
  • Each exchange distributes their order books to their clients by a combination of user interface (UI), direct data feed or data request mechanism via an application program interface (API).
  • UI user interface
  • API application program interface
  • the individual order books of the exchanges can include orders for extremely small size at price levels due to nature of Cryptocurrencies, which allows bids or offers for as little as 0.00000001 of a product.
  • Crypto-Currency is defined herein as BitCoin, Ethereum, LiteCoin or alternative coins that are based on blockchain technology.
  • the invention is a consolidated data feed and database for cryptocurrencies that processes all quotes for each product pair covered, but allows clients to access data filtered for multiple, selectable order sizes as well as for a customized subset of exchanges that specific clients are eligible to trade on at a particular point in time for the product being queried.
  • the invention includes a user interface which shows the consolidated best bid and offer filtered by multiple sizes over time, both in real time and for selectable historical periods as well as an application program interface (API) to provide the same information to clients systems.
  • API application program interface
  • FIG. 1 shows the system components and flowchart for the acquisition of the order book data, calculation of the raw and filtered book, and storage of data in order to be accessible by user interfaces and client applications.
  • FIG. 2 illustrates the User Interface for displaying the CBBO for Bitcoin/USD in realtime, on an unfiltered basis.
  • the invention covers a wide range of products, including all tradeable cryptocurrencies.
  • the market is considered “crossed” as the offer on the GDAX exchange is below the best bid on the Gemini exchange.
  • FIG. 3 illustrates the User Interface for displaying the CBBO for Bitcoin/USD in realtime, filtered for orders of 20 Bitcoin or more. Note that, despite being captured at virtually the same time as the market in FIG. 2 , the market does not appear as “crossed” due to the fact that when each exchange was filtered for orders over 20, the spreads were wider.
  • FIG. 4 illustrates the User Interface for displaying the Historical CBBO for Bitcoin/USD for a 1 day period, on an unfiltered basis. Notice that the market is considered “crossed” and that the software categorizes the magnitude of the crossed quotes as well as the % of time each of the three exchanges, in this example, are at the best bid and best offer.
  • FIG. 5 illustrates the User Interface for displaying the Historical CBBO for Bitcoin/USD for a 1 day period, filtered for orders of 20 Bitcoin or more. Notice that the filtered CBBO shows that the market is now “normal” 46% of the time and only “crossed” 54% of the time.
  • FIG. 6 illustrates the User Interface for displaying the Historical CBBO for Litecoin/USD for a 1 day period, on an unfiltered basis. Notice that the market is considered “crossed,” except for 16.3% of the time and that the software categorizes the magnitude of the crossed quotes as well as the % of time each of the two exchanges, in this example, are at the best bid and best offer.
  • FIG. 7 illustrates the User Interface for displaying the Historical CBBO for Litecoin/USD for a 1 day period, filtered for orders of 20 Litecoin or more. Notice that the filtered CBBO shows that the market is now “normal” 29.8% of the time.
  • FIG. 8 illustrates the User Interface for displaying the Historical CBBO for Ethereum/USD for a 1 day period, on an unfiltered basis. Notice that the market is considered “crossed,” except for 0.61% of the time and that the software categorizes the magnitude of the crossed quotes as well as the % of time each of the three exchanges, in this example, are at the best bid and best offer.
  • FIG. 9 illustrates the User Interface for displaying the Historical CBBO for Ethereum/USD for a 1 day period, filtered for orders of 20 Ethereum or more. Notice that the filtered CBBO shows that the market is now “normal” 12% of the time.
  • each exchange can have different APIs or methods of acquiring their book data, but the FCCBBO system will normalize all data into one format after acquisition. Therefore, whether an exchange supports an API that requires users to request quotes or the exchange has an interface that publishes all quote updates via an API in a continuous stream, the FCCBBO system will incorporate the data. Second, all of the supported filter levels will be applied to processed quote data from each exchange as it is received and will be stored in real time and historically for every supported exchange.
  • each of our clients will have their own configuration that determines which exchanges will be included in their version of the Filtered Cryptocurrency Consolidated Best Bid and Offer, which necessitates a separate layer for determining which quotes to serve via the UI or API.
  • the system has the following components: Individual feed handlers with local in-memory order-book storage, a book size and BBO processing component in the feed handler layer to create the filtered book data, a raw storage solution for the data acquired, a CBBO aggregation layer that calculates both the filtered and unfiltered best bid and offer incorporating each change of size or BBO in the individual feeds being acquired, a network-accessible, in-memory datastore to store book size and BBO metrics used by the CBBO aggregator in real time, a Real Time messaging layer to communicate between the processes, a historical database and both a UI and API which serves the data to clients.
  • Feed Handlers receive events and can also make requests to exchanges in the case that no feed-based API is available. Initially and over the course of periodic intervals, book data will be read in snapshots from exchanges. When an exchange does not have streaming support, only full book refresh will be supported. In this mode, the exchange will be polled at periodic intervals. Book size and BBO and CBBO metrics will be calculated in the same manner as with feed-based APIs, however instead of the feed handler maintaining a real-time order-book, the in-memory orderbook is simply refreshed at intervals.
  • Redundancy Multiple feed handlers will be subscribed to a single exchange/product feed at the same time for redundancy purposes. This is because in order for a real-time order book to be maintained, messages must be received roughly in order and without dropped messages.
  • Update processing When order book updates are received by the feed handler, the local in-memory orderbook is updated. Book size and BBO metrics are then calculated on the updated order-book, and written to an instance of the network accessible in-memory datastore. If any of the order book or BBO metrics have changed, a book change event is sent to the messaging layer.
  • the network accessible in-memory data structure stores book size and BBO metrics for a given exchange and product. Multiple products and/or exchanges can be stored within the same instance, and metadata is stored as to what instances of the network accessible in-memory datastore has the data for a given product and exchange.
  • Each process of the network-accessible in-memory Datastore can store book size and BBO metrics for one or more products on one or more exchanges.
  • a metadata component runs which maps a given product for a given exchange to a set of datastore instances that store the associated book size and BBO metrics.
  • Each feed handler for a product/exchange combination stores data in one or more datastore instances. This allows the scaling out of the system by adding additional instances of the datastore.
  • CBBO Aggregator A CBBO Aggregator process runs for each product, which listens for book update messages and compiles a composite order book feed based on each exchange's book size and BBO metrics. For a given product, it fetches the book size and BBO metrics from all network-accessible in-memory datastores that maintain the order book of that product for every exchange. It maintains a cache of the metadata that maps products and exchanges to instances of the in-memory datastore. The CBBO aggregator will include the most up-to-date copy of the order book for each (Exchange, Product) in the CBBO based on last updated timestamp.
  • the feed handler will send a message to the distributed messaging layer that is listened to by the CBBO Aggregator.
  • the CBBO Aggregator will calculate the full CBBO for each size threshold by aggregating the book size and BBO metrics for all applicable exchanges from the Network Accessible in-memory Datastore.
  • the CBBO values for each filter level are written to historical storage, as well as sent to the messaging layer for consumption by the UI and API.
  • the CBBO supports multiple modes of operation.
  • Tick locked mode executes the CBBO calculation inside the feed handler on a tick-by-tick basis.
  • High-throughput mode instead sends a message to the messaging layer on every book update at which point a process listening on that messaging channels calculates the updated CBBO.
  • Real Time Data Store Architecture As the system supports multiple product pairs, the architecture is such that each product pair occupies a messaging channel flow to notify the CBBO aggregator of book updates, as well as a set of datastore instances to store book size and BBO metrics for aggregation. Partitioning on the book size and BBO metrics is on the (Exchange, Product) level, meaning that if a product pair is traded on 7 exchanges, that product pair can have up to 7 datastore instances associated with it. This means the architecture scales to many products and exchanges.
  • the implementation of the Real Time Data Store utilizes an in-memory data structure store, used as a database, cache and message broker, that has built-in replication.
  • the system uses standard publish/subscribe inter-process communications.
  • API/UI functionality The system supports user configurable exchange selections and filters. It acquires these settings before initiating a query or real-time session and passes them to the API. The API then passes them to the historical or real-time data store to acquire the data requested as such data is stored with those selections in the keys. This allows the system to build the query on the fly, rather than having to calculate the results upon request.
  • the system is built to provide the CBBO and depth of book for each exchange as a central service leveraging standard cloud based architecture. As this service is designed to work directly with a Distributed Cryptocurrency Smart Order Router (DCCSOR), it can be accessed over peering connections to client instances of the DCCSOR.
  • DCCSOR Distributed Cryptocurrency Smart Order Router

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Game Theory and Decision Science (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The FCCBBO provides investors, speculators and traders in cryptocurrency products with a unique, customized data feed that solves for several problems unique to the cryptocurrency markets. The ability to filter based on order size allows for efficient scanning of available order books as well as to understand the recent historical trading patterns. This, along with the unique ability to select which exchanges should be included based on the unique account status of software users at each exchange allows for a much more contextual view of the data. While other financial markets have examples of consolidated data feeds, none of them allow for multiple size filters and no commercial feeds support customizable exchange selection based on user account status. Those features are uniquely important in the cryptocurrency markets, which is what is the driver behind this invention.

Description

    BACKGROUND
  • The Crypto-Currency1 market is served by multiple exchanges, many of which are inaccessible to investors in various jurisdictions or, at a particular moment invalid for a client to utilize due to lack of funding or available cryptocurrencies in the appropriate wallet. Each exchange distributes their order books to their clients by a combination of user interface (UI), direct data feed or data request mechanism via an application program interface (API). The individual order books of the exchanges can include orders for extremely small size at price levels due to nature of Cryptocurrencies, which allows bids or offers for as little as 0.00000001 of a product. As a result, it is extremely difficult for investors to determine the prevailing price for products they are looking to trade, at the order sizes they are interested in, particularly when they have valid accounts and the ability to trade on only one or more, but not necessarily all, exchanges. 1Crypto-Currency is defined herein as BitCoin, Ethereum, LiteCoin or alternative coins that are based on blockchain technology.
  • BRIEF SUMMARY OF THE INVENTION
  • The invention is a consolidated data feed and database for cryptocurrencies that processes all quotes for each product pair covered, but allows clients to access data filtered for multiple, selectable order sizes as well as for a customized subset of exchanges that specific clients are eligible to trade on at a particular point in time for the product being queried. The invention includes a user interface which shows the consolidated best bid and offer filtered by multiple sizes over time, both in real time and for selectable historical periods as well as an application program interface (API) to provide the same information to clients systems.
  • FIG. 1 shows the system components and flowchart for the acquisition of the order book data, calculation of the raw and filtered book, and storage of data in order to be accessible by user interfaces and client applications.
  • FIG. 2 illustrates the User Interface for displaying the CBBO for Bitcoin/USD in realtime, on an unfiltered basis. Note that the invention covers a wide range of products, including all tradeable cryptocurrencies. In this example, the market is considered “crossed” as the offer on the GDAX exchange is below the best bid on the Gemini exchange.
  • FIG. 3 illustrates the User Interface for displaying the CBBO for Bitcoin/USD in realtime, filtered for orders of 20 Bitcoin or more. Note that, despite being captured at virtually the same time as the market in FIG. 2, the market does not appear as “crossed” due to the fact that when each exchange was filtered for orders over 20, the spreads were wider.
  • FIG. 4 illustrates the User Interface for displaying the Historical CBBO for Bitcoin/USD for a 1 day period, on an unfiltered basis. Notice that the market is considered “crossed” and that the software categorizes the magnitude of the crossed quotes as well as the % of time each of the three exchanges, in this example, are at the best bid and best offer.
  • FIG. 5 illustrates the User Interface for displaying the Historical CBBO for Bitcoin/USD for a 1 day period, filtered for orders of 20 Bitcoin or more. Notice that the filtered CBBO shows that the market is now “normal” 46% of the time and only “crossed” 54% of the time.
  • FIG. 6 illustrates the User Interface for displaying the Historical CBBO for Litecoin/USD for a 1 day period, on an unfiltered basis. Notice that the market is considered “crossed,” except for 16.3% of the time and that the software categorizes the magnitude of the crossed quotes as well as the % of time each of the two exchanges, in this example, are at the best bid and best offer.
  • FIG. 7 illustrates the User Interface for displaying the Historical CBBO for Litecoin/USD for a 1 day period, filtered for orders of 20 Litecoin or more. Notice that the filtered CBBO shows that the market is now “normal” 29.8% of the time.
  • FIG. 8 illustrates the User Interface for displaying the Historical CBBO for Ethereum/USD for a 1 day period, on an unfiltered basis. Notice that the market is considered “crossed,” except for 0.61% of the time and that the software categorizes the magnitude of the crossed quotes as well as the % of time each of the three exchanges, in this example, are at the best bid and best offer.
  • FIG. 9 illustrates the User Interface for displaying the Historical CBBO for Ethereum/USD for a 1 day period, filtered for orders of 20 Ethereum or more. Notice that the filtered CBBO shows that the market is now “normal” 12% of the time.
  • DETAILED DESCRIPTION AND BEST MODE OF IMPLEMENTATION
  • The system is built upon a few basic design goals: First, each exchange can have different APIs or methods of acquiring their book data, but the FCCBBO system will normalize all data into one format after acquisition. Therefore, whether an exchange supports an API that requires users to request quotes or the exchange has an interface that publishes all quote updates via an API in a continuous stream, the FCCBBO system will incorporate the data. Second, all of the supported filter levels will be applied to processed quote data from each exchange as it is received and will be stored in real time and historically for every supported exchange. Third, each of our clients will have their own configuration that determines which exchanges will be included in their version of the Filtered Cryptocurrency Consolidated Best Bid and Offer, which necessitates a separate layer for determining which quotes to serve via the UI or API. In order to satisfy these goals, the system has the following components: Individual feed handlers with local in-memory order-book storage, a book size and BBO processing component in the feed handler layer to create the filtered book data, a raw storage solution for the data acquired, a CBBO aggregation layer that calculates both the filtered and unfiltered best bid and offer incorporating each change of size or BBO in the individual feeds being acquired, a network-accessible, in-memory datastore to store book size and BBO metrics used by the CBBO aggregator in real time, a Real Time messaging layer to communicate between the processes, a historical database and both a UI and API which serves the data to clients.
  • Feed Handlers: The feed handlers receive events and can also make requests to exchanges in the case that no feed-based API is available. Initially and over the course of periodic intervals, book data will be read in snapshots from exchanges. When an exchange does not have streaming support, only full book refresh will be supported. In this mode, the exchange will be polled at periodic intervals. Book size and BBO and CBBO metrics will be calculated in the same manner as with feed-based APIs, however instead of the feed handler maintaining a real-time order-book, the in-memory orderbook is simply refreshed at intervals.
  • Redundancy: Multiple feed handlers will be subscribed to a single exchange/product feed at the same time for redundancy purposes. This is because in order for a real-time order book to be maintained, messages must be received roughly in order and without dropped messages.
  • Recovery: If messages become too disordered due to packet loss or exchange server issues, then the feed handlers order book must be discarded, and the feed handler restarted. This duration would cause inaccuracies in the CBBO and routing logic without multiple feed handlers and order books per exchange.
  • Update processing: When order book updates are received by the feed handler, the local in-memory orderbook is updated. Book size and BBO metrics are then calculated on the updated order-book, and written to an instance of the network accessible in-memory datastore. If any of the order book or BBO metrics have changed, a book change event is sent to the messaging layer.
  • Network Accessible, In-Memory Datastore: The network accessible in-memory data structure stores book size and BBO metrics for a given exchange and product. Multiple products and/or exchanges can be stored within the same instance, and metadata is stored as to what instances of the network accessible in-memory datastore has the data for a given product and exchange. Each process of the network-accessible in-memory Datastore can store book size and BBO metrics for one or more products on one or more exchanges. A metadata component runs which maps a given product for a given exchange to a set of datastore instances that store the associated book size and BBO metrics. Each feed handler for a product/exchange combination stores data in one or more datastore instances. This allows the scaling out of the system by adding additional instances of the datastore.
  • CBBO Aggregator: A CBBO Aggregator process runs for each product, which listens for book update messages and compiles a composite order book feed based on each exchange's book size and BBO metrics. For a given product, it fetches the book size and BBO metrics from all network-accessible in-memory datastores that maintain the order book of that product for every exchange. It maintains a cache of the metadata that maps products and exchanges to instances of the in-memory datastore. The CBBO aggregator will include the most up-to-date copy of the order book for each (Exchange, Product) in the CBBO based on last updated timestamp. If a book size or BBO metric changes after a book update, the feed handler will send a message to the distributed messaging layer that is listened to by the CBBO Aggregator. On receipt of these messages, the CBBO Aggregator will calculate the full CBBO for each size threshold by aggregating the book size and BBO metrics for all applicable exchanges from the Network Accessible in-memory Datastore. The CBBO values for each filter level are written to historical storage, as well as sent to the messaging layer for consumption by the UI and API.
  • Modes of operation: The CBBO supports multiple modes of operation. Tick locked mode executes the CBBO calculation inside the feed handler on a tick-by-tick basis. High-throughput mode instead sends a message to the messaging layer on every book update at which point a process listening on that messaging channels calculates the updated CBBO.
  • Real Time Data Store Architecture: As the system supports multiple product pairs, the architecture is such that each product pair occupies a messaging channel flow to notify the CBBO aggregator of book updates, as well as a set of datastore instances to store book size and BBO metrics for aggregation. Partitioning on the book size and BBO metrics is on the (Exchange, Product) level, meaning that if a product pair is traded on 7 exchanges, that product pair can have up to 7 datastore instances associated with it. This means the architecture scales to many products and exchanges. The implementation of the Real Time Data Store utilizes an in-memory data structure store, used as a database, cache and message broker, that has built-in replication.
  • Messaging Layer: The system uses standard publish/subscribe inter-process communications.
  • API/UI functionality: The system supports user configurable exchange selections and filters. It acquires these settings before initiating a query or real-time session and passes them to the API. The API then passes them to the historical or real-time data store to acquire the data requested as such data is stored with those selections in the keys. This allows the system to build the query on the fly, rather than having to calculate the results upon request.
  • Other considerations: The system is built to provide the CBBO and depth of book for each exchange as a central service leveraging standard cloud based architecture. As this service is designed to work directly with a Distributed Cryptocurrency Smart Order Router (DCCSOR), it can be accessed over peering connections to client instances of the DCCSOR.

Claims (1)

What is claimed is:
1. A method for processing quotes for product pairs, the method comprising:
providing access to data filtered for a plurality of selectable order sizes; and
generating, for display, a user interface that includes a consolidated best bid and offer that is filtered by a plurality of order sizes over time.
US15/727,628 2017-10-08 2017-10-08 Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server Abandoned US20190325515A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US15/727,628 US20190325515A1 (en) 2017-10-08 2017-10-08 Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server
US16/754,059 US11580600B2 (en) 2017-10-08 2018-12-05 Distributed crypto-currency smart order router with cost calculator
PCT/US2018/064111 WO2019071277A1 (en) 2017-10-08 2018-12-05 Filtered, consolidated, cryptocurrency best bid and offer (fccbbo) data feed and historical data server
EP18864471.0A EP3692486A4 (en) 2017-10-08 2018-12-05 Distributed crypto-currency smart order router with cost calculator
PCT/US2018/064115 WO2019071278A1 (en) 2017-10-08 2018-12-05 Distributed crypto-currency smart order router with cost calculator
EP18864655.8A EP3692491A4 (en) 2017-10-08 2018-12-05 Filtered, consolidated, cryptocurrency best bid and offer (fccbbo) data feed and historical data server

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US15/727,628 US20190325515A1 (en) 2017-10-08 2017-10-08 Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/754,059 Continuation US11580600B2 (en) 2017-10-08 2018-12-05 Distributed crypto-currency smart order router with cost calculator

Publications (1)

Publication Number Publication Date
US20190325515A1 true US20190325515A1 (en) 2019-10-24

Family

ID=68236023

Family Applications (2)

Application Number Title Priority Date Filing Date
US15/727,628 Abandoned US20190325515A1 (en) 2017-10-08 2017-10-08 Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server
US16/754,059 Active 2038-04-12 US11580600B2 (en) 2017-10-08 2018-12-05 Distributed crypto-currency smart order router with cost calculator

Family Applications After (1)

Application Number Title Priority Date Filing Date
US16/754,059 Active 2038-04-12 US11580600B2 (en) 2017-10-08 2018-12-05 Distributed crypto-currency smart order router with cost calculator

Country Status (1)

Country Link
US (2) US20190325515A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11580600B2 (en) 2017-10-08 2023-02-14 Coinroutes Inc. Distributed crypto-currency smart order router with cost calculator

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11488243B2 (en) * 2018-05-24 2022-11-01 Royal Bank Of Canada Systems and methods for quantitative order routing
KR102252954B1 (en) * 2019-03-05 2021-05-17 주식회사 헤세그 System for trading intellectual property using block chain, and method for operating the same

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050137962A1 (en) * 2003-11-26 2005-06-23 Neill Penney Quick-filling customer asset trading system
US20050222936A1 (en) * 2004-03-31 2005-10-06 Lava Trading Inc. Cross-trading system
US20060015439A1 (en) * 2004-06-23 2006-01-19 Brann John E T Shareable quote streams
US20100293110A1 (en) * 2004-07-12 2010-11-18 Rosenthal Collins Group, L.L.C. Method and system for electronic options trading on a graphical user interface
US20170109822A1 (en) * 2014-03-21 2017-04-20 ITG Software Solutions, Inc Network communication system for exchange trading
US20170243289A1 (en) * 2016-02-18 2017-08-24 Christopher Michael RUFO Hybrid trading platform integrating fiat and crypto investments

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060136318A1 (en) 2004-01-21 2006-06-22 Lava Trading Inc. Automated system for routing orders for financial instruments
CA2626935A1 (en) 2005-11-18 2007-05-31 Chicago Mercantile Exchange Cross-currency implied spreads
US8032443B2 (en) 2006-09-28 2011-10-04 Michel Remy Everaert Systems and methods for enabling trading of currency
US8190503B2 (en) 2009-12-18 2012-05-29 International Derivatives Clearing Group, Llc Systems and methods for swap contracts management with a discount curve feedback loop
US10121196B2 (en) 2012-03-27 2018-11-06 Ip Reservoir, Llc Offload processing of data packets containing financial market data
CA3012609A1 (en) 2013-06-24 2014-12-31 Aequitas Innovations Inc. System and method for automated trading of financial interests
US10354325B1 (en) 2013-06-28 2019-07-16 Winklevoss Ip, Llc Computer-generated graphical user interface
US10269009B1 (en) 2013-06-28 2019-04-23 Winklevoss Ip, Llc Systems, methods, and program products for a digital math-based asset exchange
SG11201602075WA (en) 2013-09-17 2016-05-30 Iex Group Inc Techniques for facilitating electronic trading
US9947048B2 (en) 2014-06-04 2018-04-17 Nasdaq Technology Ab Apparatus and methods for implementing changed monitoring conditions and/or requirements using dynamically-modifiable control logic
US20150363782A1 (en) 2014-06-16 2015-12-17 Bank Of America Corporation Cryptocurrency transaction validation system
US20150363778A1 (en) 2014-06-16 2015-12-17 Bank Of America Corporation Cryptocurrency electronic payment system
US10127552B2 (en) 2014-06-16 2018-11-13 Bank Of America Corporation Cryptocurrency aggregation system
US20150363769A1 (en) 2014-06-16 2015-12-17 Bank Of America Corporation Cryptocurrency Real-Time Conversion System
US20150363770A1 (en) 2014-06-16 2015-12-17 Bank Of America Corporation Cryptocurrency Transaction Payment System
US10311515B2 (en) 2014-09-17 2019-06-04 Iex Group, Inc. System and method for a semi-lit market
US20160125533A1 (en) 2014-10-30 2016-05-05 Gordian Innovative Technologies, Limited System and method for simulating a live trading market
JP6364132B2 (en) 2015-03-31 2018-07-25 ナスダック, インコーポレイテッドNasdaq, Inc. Blockchain transaction recording system and method
WO2016164310A1 (en) 2015-04-05 2016-10-13 Digital Asset Holdings Digital asset intermediary electronic settlement platform
US20160342977A1 (en) 2015-05-20 2016-11-24 Vennd.io Pty Ltd Device, method and system for virtual asset transactions
US10033702B2 (en) * 2015-08-05 2018-07-24 Intralinks, Inc. Systems and methods of secure data exchange
KR101694455B1 (en) 2016-03-14 2017-01-17 주식회사 스트리미 Method and apparatus for exchanging or remitting blockchain-based virtual currency
US20190108586A1 (en) * 2017-10-05 2019-04-11 Baton Systems, Inc. Data ingestion systems and methods
US20190325515A1 (en) 2017-10-08 2019-10-24 David Marc Weisberger Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server
EP3692491A4 (en) 2017-10-08 2021-05-05 Coinroutes Inc. Filtered, consolidated, cryptocurrency best bid and offer (fccbbo) data feed and historical data server
US20210125278A1 (en) 2018-01-18 2021-04-29 Coinroutes Inc. System and method for calculating the executable price of a crypto-currency product pair
CN111083148A (en) * 2019-12-19 2020-04-28 紫光云技术有限公司 Method for realizing VPN gateway based on cloud computing field

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050137962A1 (en) * 2003-11-26 2005-06-23 Neill Penney Quick-filling customer asset trading system
US20050222936A1 (en) * 2004-03-31 2005-10-06 Lava Trading Inc. Cross-trading system
US20060015439A1 (en) * 2004-06-23 2006-01-19 Brann John E T Shareable quote streams
US20100293110A1 (en) * 2004-07-12 2010-11-18 Rosenthal Collins Group, L.L.C. Method and system for electronic options trading on a graphical user interface
US20170109822A1 (en) * 2014-03-21 2017-04-20 ITG Software Solutions, Inc Network communication system for exchange trading
US20170243289A1 (en) * 2016-02-18 2017-08-24 Christopher Michael RUFO Hybrid trading platform integrating fiat and crypto investments

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11580600B2 (en) 2017-10-08 2023-02-14 Coinroutes Inc. Distributed crypto-currency smart order router with cost calculator

Also Published As

Publication number Publication date
US20200327611A1 (en) 2020-10-15
US11580600B2 (en) 2023-02-14

Similar Documents

Publication Publication Date Title
US11231977B2 (en) Distributed processing in a messaging platform
CN106874424B (en) A kind of collecting webpage data processing method and system based on MongoDB and Redis
CN106294486B (en) Financial market data processing method and system
US20190325515A1 (en) Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server
US9420050B1 (en) Log reporting for a federated platform
US11522976B1 (en) Method, apparatus and system for subscription management
US9722891B2 (en) Method and system for generating and providing data alerts
JP5216779B2 (en) Intelligent information distribution
US11283725B2 (en) Event content delivery
US11636543B2 (en) Distribution of market data based on price level transitions
AU2014221320B2 (en) System and method for displaying trade information for electronic trading exchange
DE102015206993A1 (en) System and method for performing synchronized trading activities on multiple exchanges
US10636095B2 (en) Method and apparatus for publishing market information
AU2017378245B2 (en) Systems and methods for aggregating, filtering, and presenting streaming data
WO2019071277A1 (en) Filtered, consolidated, cryptocurrency best bid and offer (fccbbo) data feed and historical data server
AU2017204208A1 (en) Informational incentives for submitting maker orders
WO2016021019A1 (en) Market-price processing system
US7523213B1 (en) Efficient approach with the toleration of stale data to dynamically transform and unify data quality in client and server with continuous transaction flows
US11037243B2 (en) Dynamic dissemination of information to network devices
US20210312550A1 (en) System and method for low latency multi-market order book consolidation
WO2019116123A1 (en) System for processing coherent data
Frischbier et al. A real-world distributed infrastructure for processing financial data at scale
US20240046343A1 (en) Method, apparatus and system for auction of assets
CN116743558A (en) Concurrent traffic monitoring method, device, terminal equipment and storage medium
Macleod et al. Implied-Volatility Grid: Grid Based Integration to Provide On Demand Financial Risk Analysis

Legal Events

Date Code Title Description
AS Assignment

Owner name: COINROUTES INC., NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WEISBERGER, DAVID MARC;WEISBERGER, IAN JOSEPH;REEL/FRAME:047677/0030

Effective date: 20181204

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION