WO2022058971A1

WO2022058971A1 - System and method for on-line trading with flexible bet creation

Info

Publication number: WO2022058971A1
Application number: PCT/IB2021/058524
Authority: WO
Inventors: Alexander Gofman
Original assignee: Markets Bettors
Priority date: 2020-09-21
Filing date: 2021-09-19
Publication date: 2022-03-24

Abstract

A system and method for on-line trading are provided including: receiving event updates transmitted from one or more event feed services; receiving bet offers from multiple respective user computing devices; receiving a bet query from a querying user computing device of the multiple user computing devices; determining that bet terms of a subset of the stored bet offers match the query terms and responsively transmitting the subset of the stored bet offers to the querying user computing device; storing a bet contract including a record of the bet terms of the accepted bet offer; receiving from the event updates an outcome of an event having an event identifier of the stored contract; and, according to the target outcome, crediting or debiting the bet offeror's and bet acceptor's accounts.

Description

SYSTEM AND METHOD FOR ON-LINE TRADING WITH FLEXIBLE BET CREATION

FIELD OF THE INVENTION

[0001] The present invention generally relates to the field of on-line trading platforms.

BACKGROUND

[0002] As financial markets evolve, investors are constantly looking for improved means to achieve higher revenues and better rates of return, while also taking advantage of the efficiencies of on-line trading. Unfortunately, on-line trading typically limits the type of bet that can be made, forcing users to choose between pre-set categories and ranges. In addition, investors may also have to make bets through brokers, who may have conflicts of interest. Embodiments of the present invention have been developed to address these shortcomings.

SUMMARY

Embodiments of the present invention provide a system and methods for on-line trading, by which transactions are implemented between monetary accounts of users offering bets and of users accepting bets.

[0003] A system for on-line betting is thereby provided, the system including multiple user computing devices and an internet-accessible server. The server includes a processor with accessible memory including instructions that when executed by the server processor implement a process that may include steps including receiving event updates transmitted from one or more event feed services, wherein each event update is a record including an event identifier and an event outcome. Steps may further include receiving bet offers from multiple respective user computing devices of the multiple user computing devices and to store the bet offers in the server-accessible memory. Each bet offer is a record including an identity of a respective bet offeror and bet terms input by the respective bet offeror at a respective user computing device. The bet terms may include an event identifier, a target outcome of the identified event, and respective win and loss settlement amounts. The win settlement amount is an amount to be paid to the bet offeror by a bet acceptor if a respective target outcome is achieved, and the loss settlement is an amount to be paid to the bet acceptor by the bet offeror if a respective target outcome is not achieved.

[0004] Steps may further include receiving a bet query from a querying user computing device of the multiple user computing devices. The querying user computing device is operated by a querying user, and the bet query is a record including an identifier of the querying user and query terms including a range of bet terms.

[0005] The processor may be further configured to determine that bet terms of a subset of the stored bet offers match the query terms and responsively to transmit records of the subset of the stored bet offers to the querying user computing device. The processor may then receive from the querying user computing device an authorization to accept one of the subset of the bet offers, where the authorization is input to the querying user computing device by the querying user, making the querying user a bet acceptor.

[0006] The processor may be further configured to store a bet contract in the accessible memory including a record of the bet terms of the accepted bet offer and the identities of the bet offeror and bet acceptor. The processor may then receive from the event updates an outcome of an event having an event identifier of the stored contract, and the processor may be further configured to then compare the outcome with the target outcome to determine whether the target outcome was achieved. When the target outcome is achieved, the processor may perform a first transaction crediting the win settlement amount to a bet offeror’s monetary account and debiting the win settlement amount from a bet acceptor’s monetary account, and when the target outcome is not achieved, the processor may perform a second transaction debiting the loss settlement amount from the bet offeror’s monetary account and crediting the loss settlement amount to the bet acceptor’s monetary account.

[0007] The processor may be further configured to deduct transaction fees from the bet offeror’s account and from the bet acceptor’s account. The event may be a sporting event, an event of nature, or a future price of an asset traded on a recognized exchange (i.e., an exchange that publishes asset prices), or any other event broadcast by an exchange or news feed. An identity of the event may include an identity of an exchange on which the event is traded.

[0008] Typically, the bet terms offered are not limited to a predefined set of values.

[0009] Further embodiments may include receiving, from the user computing devices of the bet acceptor and of the bet offeror, authorizations to transfer funds to cover potential losses to the respective bet acceptor and bet offeror accounts.

[0010] In further embodiments, the user computing devices are configured to present a form for the bet offerors to enter the bet terms of the bet offers and to present a form for the bet acceptor to enter one or more ranges of bet terms when creating the bet query.

[0011] User interfaces of the user computing devices may include feeds of relevant financial news for asset prices and feeds of sports news for relevant news of sporting events. A user interface of the user computing devices may also include a friends activity panel for entering and presenting posts by friends who have monetary accounts. The user interface of the user computing devices may include options for viewing open bets, bet history, and options for depositing and withdrawing funds from user accounts.

[0012] Subsets of users may be recorded as friends in a database of users. Determining that the subset of the stored bet offers match the bet query may include limiting the subset to bet offers of bet offerors who are friends of the bet acceptor. In some embodiments, generating the bet contract is performed only if the bet offeror and the bet acceptor are friends.

BRIEF DESCRIPTION OF DRAWINGS

[0013] For a better understanding of various embodiments of the invention and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawings. Structural details of the invention are shown to provide a fundamental understanding of the invention, the description, taken with the drawings, making apparent to those skilled in the art how the several forms of the invention may be embodied in practice. In the figures:

[0014] Fig. 1 is a schematic diagram of a system for flexible, on-line trading, in accordance with an embodiment of the present invention;

[0015] Fig. 2 is a schematic diagram of a front-end interface for a flexible, on-line trading system, in accordance with an embodiment of the present invention; and

[0016] Fig. 3 is a schematic diagram of a flow chart of transaction execution in a system for flexible, on-line trading, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

[0017] Embodiments of the present invention provide a product and methods for a platform that enables users to meet independently, that is, without the manual involvement of brokers or agents. Users generate bilateral bets, also referred to herein as bet contracts, that is, commitments obligating users to the terms of the bet. Bets may be for financial "binary options," also referred to in the financial industry as "all-or-nothing options," "digital options," and "fixed return options." Bet terms typically set an event outcome, a strike time, and a settlement amount. Such a bet establishes that a user will receive a payout or lose their investment, based on whether or not a price of the underlying event is above or at the event outcome at the “strike time,” that is, the time and date when the event is to occur. In other words, bet offers define an outcome that will either be met or not, that is, they are a "yes or no" proposition.

[0018] Events may be the prices quoted at a given “strike time” for assets that are traded on major financial exchanges, such as exchanges for stocks or foreign currency. That is, the “event outcome” defined in a bet offer may be the price of such an asset at the strike time. “Events” may also be any other types of events that can be defined as having a binary outcome at a specified time. For example, a game played between two teams, such as baseball teams, can be defined as the event of a bet offer.” The event outcome could be defined as a win by one of the teams, the “strike time” being the end of the game. In embodiments of the present invention, underlying events for bets may be any events that have outcomes that are published by recognized sources (such as by a market or exchange that provides a price feed to the system, so that settlements are automated, or a news service providing sporting event results).

[0019] The system may be configured to take a service fee, typically from the winning side, upon the expiration of a bet (i.e., at the “strike time” set by the terms of the bet offer).

[0020] The system provides users with two methods for creating bets. One method is to create bet specifications that are then offered to other users. The other method is to accept a bet specification from a list of such specifications that users have previously created. Typically the system will only permit bets between users with sufficient funds in their accounts to cover the bet if they lose. Once a bet offer by one user has been accepted by another user, a bet contract is established. The system then enforces the bet terms, transferring funds to the winner, from the loser, upon expiration of the bet.

[0021] As described hereinbelow, the system also includes a user interface that promotes socializing between users, encouraging users to invite friends, to create social groups, and in general to socialize, trade, learn and compete with each other.

[0022] Fig. 1 is a schematic diagram of a system 20 for flexible, on-line trading, in accordance with an embodiment of the present invention. The system includes an internetbased server, referred to herein as a trading platform 22, which may be a cloud-based server, or other type of data center or distributed computing server.

[0023] The system also includes user computing devices, such as client platforms 30 and 32. The system also includes "back-office" modules 34 for generating and managing data presented as user interfaces 36 of the client platforms, as well as for general administration of the system. Based on the data provided by the back-office modules and based on the configurations of the user interfaces 36, the client platforms may be, for example, web browser-based interfaces or mobile applications. As described further hereinbelow, the user interfaces include at least three modules: a trading zone, a public dashboard, and a personal zone, referred to as "My Zone."

[0024] The back-office modules may include the following elements:

[0025] 1. News and events feed. This module may be an interface to feeds of relevant news and events from relevant sources of financial news, that is, news related to the underlying events of bets that are trading on the system. In some embodiments, the system provides users with options to select which feeds they want to see in their dashboard.

[0026] 2. Members (users) registration info. Users create accounts that enable them to trade by entering personal information, which may also be reviewed manual by administrators. In addition, users typically provide bank information for transferring funds to accounts of the system, which are maintained by user, ensuring that the system has control over user funds in order to execute transactions.

[0027] 3. Dashboard (forum) posts/comments. A social media-type of user interface enables users registered with the system to exchange opinions and to post relevant news.

[0028] 4. Member monetary account management, managing deposits, withdrawals, and transactions (i.e., monetary transfers) between accounts. The system may include a banking interface for managing transfers of user funds to and from established banks.

[0029] 5. Bet records. The system maintains current and historical records of all bet contracts entered into between users, as well as of all bet offers made by bet offerors.

[0030] 6. Company Accounting. An accounting subsystem links revenue and costs of the system administrator to the relevant aspects of the trading platform, such as system fees collected on transactions.

[0031] 7. User activity or inactivity log. Various actions of users may also be tracked for users to be able to review their activities.

[0032] 8. Event price feeds ("market tickers"). The system includes feeds to market tickers of exchanges whose events may be traded on the platform. The system checks the feeds upon expiration of bets to determine bet "winners."

[0033] 9. Administrator configurations. An administrator interface allows various options, such as API feeds, event categories, events, commission rates, etc., to be set and changed.

[0034] Fig. 2 is a schematic diagram of a front-end interface 200 for a flexible, on-line trading system, in accordance with an embodiment of the present invention. [0035] Users who register for trading and are approved may then execute a login 202 to the system. Typically, the user interface is web-based or operated as a "mobile app." The home page 204 of the user interface typically includes a menu or a variety of sections that include several interfaces, called "zones," including: a Trading Zone (206), a Dashboard (208), and a personal zone, called "My Zone" (210).

[0036] TRADING ZONE (206):

[0037] Typically the user interface permits access to the "Trading Zone" from every page of the user interface, by means of a “Trading” button on the user's screen. From the trading zone screen, a user can see a general list of bet specifications that have been offered by users. A user may also generate a list by entering a query indicating ranges of bet terms. For example a query may specify an identity of an underlying event for a bet (such as a symbol of an event, as defined by the exchange on which an underlying asset is traded; e.g., AAPL, for stock of Apple Inc., or GBP, for British Pound). A user may also generate a list by searching all bet specifications that are offered related to a given type of event, such as an asset price of an asset traded on a given exchange (e.g., NASDAQ), or a type of sport (e.g., baseball).

[0038] A user may also make a query that indicates the user’s preferred ranges for bet terms, including strike time, event outcome, and settlement amount. For example, a query or search may request a list of all bet specifications that are offered with settlement amounts less than $100, or that have a “strike time” of a specific day, such as June 10.

[0039] After executing a search and getting a list of appropriate bet offers, a user can typically accept a specific bet offered.

[0040] Also from the trading zone screen, a user can create a new bet specification that is offered to the other users, by setting terms including: event, expiration, or “strike” time (i.e., date and time that event occurs), event outcome being bet by the bet creator, and settlement amount (i.e., the amount of the "bet"). A “return ratio” may also be specified if user thinks is betting for or against a long shot, that is, an event outcome that does not have a 50/50 chance of occurring.

[0041] For example, a bet specification may be offered by a user, specifying the event as a price of gold, the strike time being 11:10 a.m. the following day, the event outcome being bet being that the price will be $1000 or more, and a settlement amount (i.e., amount being bet) of $100. That is, the user will pay $100 if the outcome is not achieved, meaning that the user who makes the offer loses, and the user who accepts the offer wins. The user making the offer may alternatively specify an event outcome that he believes has long odds, such as a price of $1500 or more, and may specify an offer of a non-symmetric settlement price, such as $100 reward/ $500 risk, whereby the user will pay (i.e., pay the reward) of $100 if the price of gold does not hit $1500, but will receive from the loser (for whom losing is the risk) $500 if the price is at or above $1500.

[0042] The trading zone may also include an option for creating multiple bet offers based on an initial offer. A user may use this function to split a large bet offer into multiple smaller offers that may be more easily accepted by users with smaller levels of funds.

[0043] A similar bet specification might be created with respect to other financial assets, such as an exchange-traded stocks, bonds, currencies or cryptocurrencies, as well as options or other commodities. A similar bet specification might also be created for a sporting event, the main difference being that the “strike time” is typically a time with respect to the game, such as an end-of-game, or a half-time of the game. For example, for a sporting event between a team A and a team B, the strike time could be set to “end-of- game” and the outcome could be set to “team A to win.” Alternatively, the event outcome could be set to “team A to win by at least 10 points.” The settlement price could alternatively be set to non-symmetric terms, such as $1000 reward / $2000 risk.

[0044] Other events that may be specified as underlying bets may include: political events, such as election results, or natural events, such as earthquakes or weather events. For example, a user may select an earthquake event, specifying an outcome of “no earthquake in the Ukraine of greater than 5.0 Richter scale magnitude by the end of the year.” Given that such earthquakes are not frequent, the user making this offer is betting against a long shot, and would typically set a non-symmetric settlement price such as $1000 reward / $100 risk, meaning he would pay $1000 if the earthquake occurs, and would take $100 if it does not occur.

[0045] As described above, a bet specification on a financial asset typically specifies that the user is either betting that the bet will be "in the money," i.e., above the specified amount, or "out of the money," i.e., below the specified amount. Typically, offers are offered for a limited time period, after which the offer is cancelled. For example, a user may specify that his offer will expire after one day, or after a certain percent of the time remaining before the strike time has passed (e.g., 25% of time until the strike time). The expiration of offers may be configured by users or set by the system.

[0046] A user may also generate a new bet offer to close the user’s obligation with respect to an existing bet, transferring the obligations (and potential benefits) to a third party. The new bet offer would include all terms of the original bet, together with a price that the user would either receive or pay to a third party assuming the bet contract.

[0047] Typically, a user's "free margin," that is, the funds he has available for making bets, is reduced when a bet is offered by the settlement amount of the offer. For asymmetrical settlement prices, the higher amount is typically deducted from the free margin. When a bet is cancelled, the settlement amount is typically returned to the user’s balance. A cancellation fee may also be charged to the user. Typically, both the users who create bet offers and the users accepting such offers are warned by the trading platform before executing a contract of the financial implications of such actions.

[0048] As described above, the platform is typically connected to a variety of market tickers, allowing the platform to automatically monitor outcomes (e.g., scores or prices) of events upon which bets are made. When a bet contract expires at the strike time, the outcome of an asset bet is determined by the price of the relevant market ticker, while the outcome of a sporting event may be determined by a sports news feed. Alternatively, human administrators of the trading platform may manually enter results when feeds are not available (for example, for outcomes of events of nature, such as natural disasters). Account balances of the users participating in the bet are then adjusted accordingly, as described below.

[0049] THE DASHBOARD (208):

[0050] The "Dashboard" zone of the user interface may include a “Latest News” feed and an "Opinions" feed. The "Latest News" will typically include the most current news and articles from the financial and business world. The articles are typically posted with a feedback section, and users are encouraged to comment and to discuss the articles. In the “Opinions” feed, users can share their own thoughts, for example as posts, tweets or blogs. Users are notified about posts according to preferences they set. Users can view posts from other users they chose to follow.

[0051] Additionally or alternatively, the "Dashboard" may include Price Feeds (Market tickers) including adjustable timelines and analysis tools, which may help users to evaluate price trends of assets. [0052] MY ZONE (210):

[0053] Whereas the Dashboard includes public feeds, open to all users, the "My Zone" sections of the user interface have sections that are personal. These include, for example, a “Friends & Activities” feed, which is based on a user’s communications with friends or closed groups, according to a timeline of such communications. From "My Zone" users can request to be a "friend" of another user, whereby the trading platform forwards the request to the second user, and once, the second user approves, the "friendship is recorded by the trading platform. Users can also create a group (i.e., "circle") from among their friends, with whom they can communicate as a group. Users can also query bet offers limited to their friends or groups. In some implementations of the platform, search results may be restricted to bets offered by friends. In additional or alternative implementations, search results may show all bets offered (that meet the search criteria), but trades are restricted to trades between users that are "friends."

[0054] The "My Zone" screen also typically links a user to additional account management screens, such as open bets, bet history, account management tasks (such as changing contact information and passwords), and funds management (for deposits and withdrawals). A user may also specify phone and email addresses to get system notifications, for example by SMS or email, regarding alerts, such as bets that come into force or expire.

[0055] In "My Zone" a user may also include tools for enabling users to generate privately maintained functions for analyzing asset prices or other relevant trends (e.g., candidate popularity with respect to an election). Mathematical functions for trends may include functions with respect to price histories and trends. [0056] In short, the user interface provides trading functions, including creating bet offers, by entering bet specifications (i.e., bet terms), searching for bets offered, and accepting bets. The user interface may also include social media tools, such as screens for communicating, writing tweets, discussing news, both with other users and with friends and groups of friends.

[0057] Additional options of the trading platform include adding funds, withdrawing funds, monitoring funds, monitoring bets, and creating and deleting accounts.

[0058] Fig. 3 is a schematic diagram of a flow chart of a transaction process 300 of the system for flexible, on-line trading, in accordance with an embodiment of the present invention.

[0059] At a first step 302, two users (1 and 2) who will subsequently enter into a bet contract add funds to their monetary accounts. For example, user 1 may deposit $X₁ in their account, such that they have a "balance" of $X₁ and also a "free margin" (amount available for additional bets) of $X_x assuming that they have not yet created or accepted any bet offers. Similarly, user 2 may deposit $X₂ in their account, such that they have a balance of $X₂ and also a free margin of $X₂ assuming that they have not yet created or accepted any bet offers.

[0060] At a next step 304, user 1 creates bet specifications for an offer. The offer includes a settlement amount, i.e., a possible "win/loss," of $Y. The platform typically allows users to enter bets on any underlying events for which the platform has a market feed (i.e., an "event feed" or “ticker feed”). The platform also typically allows users to specify the bet expiration times (i.e., strike times), event outcomes, and settlement amounts

(win and/or loss) as the user making an offer sees fit. That is, these terms typically are not limited to a set of preset values. Typically, a “target outcome” of the bet offer is the outcome by which the offeror will “wins” the bet. Conversely, if the target outcome is not achieved, the bet offeror will lose the bet and the bet acceptor will win.

[0061] Typically, the user interface includes a form for users to enter bet terms into fields of the form when creating a bet specification. The forms may be configured to provide, for one or more fields, lists of options from which a user can select (e.g., lists of assets or other types of events that can be selected for setting target outcomes). Alternatively, or additionally, some fields can be filled with free text, particularly the strike time and settlement amount. (Terms, such asymmetrical settlement prices, may be set at what may appear to be “unreasonable” values, but it is typically assumed that if term values are unreasonable, the bet offer will not be accepted by other users.)

[0062] After user 1 creates a bet offer, the account “balance” for user 1 is still $Xi (the original deposit amount) but the free margin of user 1 is reduced to the amount of $Xi - $Y, which may be written as $Fi. (Alternatively, the platform may not deduct the settlement amount from a free margin of a user at the time a bet is offered, but rather only deduct the amount at the time a bet is accepted.)

[0063] Subsequently, at a step 306, user 2 runs a search for attractive offers, and the platform responds with a list of matching bet offers. Assuming that the bet offered by user 1 meets the criteria of the search entered by user 2, the offered bet will be presented to users 1 among the search results of bet offers. User 2 may then accept the bet offered by user 1, causing the platform to establish a bet contract between the two users (i.e., storing a record of the established contract). Now, the balance of user 2 is still $X2 but the platform set the free margin of user 2 to $X2 - $Y, which may be written as $F2 (assuming a symmetrical settlement price of $Y). [0064] At a step 308, the platform determines a winner and a loser from between the bet offeror and bet acceptor (users 1 and 2, respectively), based on whether the target outcome was achieved. This may be, for example, if price of the underlying option was "in the money" or "out of the money," as determined by a feed from the relevant source.

[0065] If user 1 wins, then (at a step 310), the settlement amount $Y is added to the user's account, minus any commission applied by the trading platform. For example, a commission for a win may be set to $Z_W, and consequently the amount in the user's balance after the settlement of the bet will be $X + $Y - $Z_W. This will also be the free margin, assuming user 1 has no other outstanding bets. (The commission may alternatively be set to be a percent of the settlement amount.)

[0066] If user 1 loses, then (at a step 312), the settlement amount is subtracted from the user's account, minus any commission or compensation applied by the trading platform. In some implementations, a loser pays only the settlement amount, receiving no compensating amount and paying no additional fees. In an alternative implementation, a compensating amount for a loss may be set by the platform to $ZL, and consequently the amount in the user's balance after the settlement of the bet would be $X - $Y + $Z_W. This would also be the free margin after the settlement, assuming user 1 has no other outstanding bets. (Any compensation, like the commission amount, may alternatively be set to be a percent of the settlement amount rather than a fixed amount.)

[0067] Obviously, the accounts of user 2 would follow the same patterns for win and loss as those described above for user 1.

[0068] It is to be understood that all or part of system 20, of the user interface 200, and of the transaction process 300 can be implemented as a computing system in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. The computing system may have one or more processors and one or more network interface modules. Processors may be configured as a multi-processing or distributed processing system. Network interface modules may control the sending and receiving of data packets over networks. Security modules control access to all data and modules. All or part of the system and process can be implemented as a computer program product, tangibly embodied in an information carrier, such as a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, such as a programmable processor, computer, or deployed to be executed on multiple computers at one site or distributed across multiple sites. Memory storage may also include multiple distributed memory units, including one or more types of storage media.

[0069] Method steps associated with the system and process can be rearranged and/or one or more such steps can be omitted to achieve the same, or similar, results to those described herein. It is to be understood that the embodiments described hereinabove are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.

Claims

1. A system for on-line betting, comprising multiple user computing devices and an internet-accessible server, the server comprising a server processor with server- accessible memory including instructions that when executed by the server processor implement a process comprising: receiving event updates transmitted from one or more event feed services, wherein each event update is a record including an event identifier and an event outcome; receiving bet offers from multiple respective user computing devices and storing the bet offers in the server-accessible memory, wherein each bet offer is a record including an identity of a respective bet offeror and bet terms input by the respective bet offeror at a respective user computing device, wherein the bet terms include an event identifier, a target outcome of the identified event, and respective win and loss settlement amounts, wherein the win settlement amount is an amount to be paid to the bet offeror by a bet acceptor if a respective target outcome is achieved, and the loss settlement is an amount to be paid to the bet acceptor by the bet offeror if a respective target outcome is not achieved; receiving a bet query from a querying user computing device of the multiple user computing devices, wherein the querying user computing device is operated by a querying user, and wherein the bet query is a record including an identifier of the querying user and query terms including a range of bet terms; determining that bet terms of a subset of the stored bet offers match the query terms and responsively transmitting records of the subset of the stored bet offers to the querying user computing device; receiving from the querying user computing device an authorization by the querying user to be a bet acceptor to accept one of the subset of the bet offers; storing a bet contract in the server-accessible memory including a record of the bet terms of the accepted bet offer and the identities of the bet offeror and bet acceptor; receiving from the event updates an outcome of an event having an event identifier of the stored contract; comparing the outcome with the target outcome to determine whether the target outcome was achieved; and when the target outcome is achieved, performing a first transaction crediting the win settlement amount to a bet offeror’ s account and debiting the win settlement amount from a bet acceptor’s account, and when the target outcome is not achieved, performing a second transaction debiting the loss settlement amount from the bet offeror’s account and crediting the loss settlement amount to the bet acceptor’s account.

2. The system of claim 1, further comprising deducting transaction fees from the bet offeror’s account and from the bet acceptor’s account.

3. The system of claim 1, wherein the event is a sporting event.

4. The system of claim 1, wherein the event is an event of nature.

5. The system of claim 1, wherein the event is an asset price at a future time and date, of an asset trading on an exchange that publishes asset prices.

6. The system of claim 1, wherein the identity of the event includes an identity of an exchange on which the event is traded.

7. The system of claim 1, wherein at least one of the bet terms is not limited to a predefined set of values.

8. The system of claim 1, further comprising receiving, from the user computing devices of the bet acceptor and of the bet offeror, authorizations to transfer funds to cover potential losses to the respective bet acceptor and bet offeror accounts.

9. The system of claim 1, wherein the user computing devices are configured to present a form for the bet offerors to enter the bet terms of the bet offers.

10. The system of claim 1, wherein the user computing devices are configured to present a form for the bet acceptor to enter one or more ranges of bet terms when creating the bet query.

11. The system of claim 1, wherein a user interface of the user computing devices includes a feed of relevant financial news.

12. The system of claim 1, wherein a user interface of the user computing devices includes a feed of relevant sports news.

13. The system of claim 1, wherein a user interface of the user computing devices includes a friends activity panel for entering and presenting posts by friends who have accounts on the trading platform.

14. The system of claim 1, wherein a user interface of the user computing devices includes options for viewing open bets, bet history, and options for depositing and withdrawing funds.

15. The system of claim 1, further comprising recording subsets of users as friends, and wherein determining that the subset of the stored bet offers match the bet query comprises limiting the subset to bet offers of bet offerors who are friends of the bet acceptor.

16. The system of claim 1, further comprising recording users on the platform as friends, and generating the bet contract only if the bet offeror and the bet acceptor are friends.

19

17. A computer-based method for on-line betting implemented by an internet-accessible server in communication with multiple user computing devices, the method comprising: receiving event updates transmitted from one or more event feed services, wherein each event update is a record including an event identifier and an event outcome; receiving bet offers from multiple respective user computing devices and storing the bet offers in the server-accessible memory, wherein each bet offer is a record including an identity of a respective bet offeror and bet terms input by the respective bet offeror at the respective user computing device, wherein the bet terms include an event identifier, a target outcome of the identified event, and respective win and loss settlement amounts, wherein a win settlement amount is an amount to be paid to the bet offeror by a bet acceptor if a respective target outcome is achieved and a loss settlement is an amount to be paid to the bet acceptor by the bet offeror if a respective target outcome is not achieved; receiving a bet query from a querying user computing device of the multiple user computing devices, wherein the querying user computing device is operated by a querying user and wherein the bet query is a record including an identifier of the querying user and query terms including a range of bet terms; determining that bet terms of a subset of the stored bet offers match the query terms and responsively transmitting the subset of the stored bet offers to the querying user computing device; receiving from the querying user computing device an authorization by the querying user to be the bet acceptor and accept one of the subset of the bet offers; storing a bet contract in the server-accessible memory including a record of the bet terms of the accepted bet offer and the identities of the bet offeror and bet acceptor;

20 receiving from the event updates an outcome of an event having an event identifier of the stored contract; comparing the outcome with the target outcome to determine whether the target outcome was achieved; and when the target outcome is achieved, performing a first transaction crediting the win settlement amount to a bet offeror’s account and debiting the win settlement amount from a bet acceptor’s account, and when the target outcome is not achieved, performing a second transaction debiting the loss settlement amount from the bet offeror’s account and crediting the loss settlement amount to the bet acceptor’s account.

21