...

1. Player picks the selection(s), enters stake and makes the bet attempt.

2. The bet attempt is now sent to Bet Assessment API, that is responsible for accepting or rejecting the bet.
   Recommended option is to use our Bet Assessment API together with Ably: If there is a bet delay applied then the Bet Assessment API returns the bet status delayed and the assessment result is returned via Ably messaging after the configured bet delay value (see Appendix D for how to receive Ably messages).

3. a. If Bet Assessment API rejects the bet attempt, it would be returning the reason behind the rejection in the message - which you can then present on the betslip for the player, and new bet attempt can be done.
   b. if Bet Assessment API accepts the ticket, then the bet attempt is successful and player should receive immediate confirmation on that.

4. All the accepted bets should immediately be sent to Bet Feed Receiver API - these bets would then count towards liability calculation and GTS team would also have visibility of these tickets in the Bet Ticker/Bet Scroller.

5. Whenever the bet is settled, an update is required to be sent into Bet Feed Receiver API. Generally this happens after receiving settlement message from us into your back-end, but we also expect to receive updates for example, if player cashes the ticket out or you decide to void/cancel a ticker for a particular reason.
   After Bet Feed Receiver API has received the settlement, our reporting environment in Power BI, will be updating the numbers accordingly. You would also be granted access to BI, where you can track all the results, KPIs, player data and much more.

...

...

It is very important to understand the concept of the System Bet Type Definition we use to describe system bet types in data contracts below. Please see Appendix A for a list of system bet types we support at the moment.

In the case of Single, Multi, and System bets, the bet is represented by a number of legs.

A Single is a bet that has only one leg.

For a Multi Bet (which is a bet that has multiple legs) to win, each of the supplied legs must win.

A System Bet is also a bet that has multiple legs, but in addition to them, it has a set of variable-length combinations of these legs. Each combination can win, and for any individual combination to win, each of its legs must win. A System Bet may therefore contain both winning and losing combinations.

To define these combinations, we use an array of numbers that refer to the number of legs in the combination. Let's take a bet with 3 legs - A, B, and C.

1. If we want to define a system bet as a combination of two legs (doubles), i.e. AB, AC, and BC, we use [2]. We call it "BXMUL-2L" in Appendix A.

2. If we want all possible combinations (singles, doubles and trebles), i.e. A, B, C, AB, AC, BC, and ABC we use [1, 2, 3]. We call it “PATENT” in Appendix A.

Bet Assessment API

Overview

...

• [OPTIONAL] - but recommended! Is it safe for the bookmaker to accept this bet, based on the current selection status and price?

  • priceChangeRule property needs to be sent with the assessment request to have selections status and price checked as a part of the assessment. Further details are given in https://geniussports.atlassian.net/wiki/spaces/BID/pages/4396679262/Risk+ServicesGTS+Integration#Root-object

  • The price change tolerance is configurable per customer (bookmaker). It is a price change in percentage. For example if the price is changed from 1.91 to 1.77 then the change is 7.33%. Please contact your Genius Sports Customer Integration Manager for the initial set up of the price change tolerance.

• Is it safe for the bookmaker to accept this bet, based on current liability and limits on player and selection(s)?

• What is the maximum stake that can be placed on this bet based on the current price, liability, and limits on player and selection(s)?

• In the case of InPlay betting, how long should I artificially delay acceptance of the bet? The exact behavior depends on the customer’s integration option:

  • OPTION 1 (Recommended) - Bet delay handled by GTS, HTTP REST API, and Messaging Integration

    • The configured bet delay is implemented as part of the bet assessment process and is handled by GTS. In addition to returning the bet delay value in the assessment response, the bet delay is already implemented on our side. When the bet is delayed, then the REST API assessment response has the betAssessmentResult = AssessmentDelayed and the bet assessment result is returned via Ably messaging after the configured bet delay value.

  • OPTION 2 - Bet delay handled by the customer, only HTTP REST API Integration

    • The configured suggested bet delay is returned in the assessment response betDelay property, and it is up to the customer's system to implement the delay or decide not to. The customer should check the market and selection status and price after the suggested bet delay and if it is changed then they should send a new assessment request with the new price.

  • The Bet Delay value is configured in the GTS by Genius Sports risk analysts. It is possible to configure it on different levels (sport, competition, fixture, market).

• The detailed explanation of the assessment process is described here GTS Bet Assessment Calculations.

...

NB! The selections Ids sent to OddsFeed Platform Ingestion API, Bet Feed Receiver API bookmakerContent and Bet Assessment API requests need to match.

System Bet Types Definitions

It is very important to understand the concept of the System Bet Type Definition we use to describe system bet types in data contracts below. Please see Appendix A for a list of system bet types we support at the moment.

...