Managed trading services (MTS)

Overview

The MTS provides functionalities to monitor bookmaker bets and dynamically adjust the odds based on the stakes amounts. Additionally, the platform can determine whether a potential bet would violate any established restrictions.

Features

• Real-Time Bet Tracking and Feed Modification:

  • The platform continuously monitors all bets placed with bookmakers.
  • Odds values are adjusted dynamically according to the amounts staked.

• Restriction and Compliance Check:

  • Before a bet is placed, the MTS evaluates it against a set of predefined restrictions (e.g., betting limits, user eligibility).
  • If the bet violates any restriction, the platform provides list of restrictions why the bet cannot be placed.
• API Integration:
  • Each bet placement is processed in real-time through the MTS API.
  • The API responds with either:
    • A confirmation of successful bet placement.
    • A list of restrictions that prevent the bet from being placed.

Bet Placement Workflow

1. Bet Placement Request: A request is sent to the MTS API containing the bet data (e.g., stake amount, odds, player ID).
2. Validation and Risk Assessment: The platform validates the bet against its internal rules and risk parameters. The system checks for any limits or restrictions that may apply to the bet or player.
3. API Response:
   1. Successful Response: If all checks are passed, the bet is accepted and confirmed via the API.
   2. Error Response: If the bet violates any restriction or exceeds limits, the API returns an error with a detailed list of restirctions.

CashOut

Overview

CashOut is a feature that allows an early withdrawal of funds from an active bet before the odds (selections/markets) are settled. This option is available when the player decides to settle the bet prematurely, minimizing potential losses or securing a portion of the winnings.

How CashOut Works

1. Bet Placement: A player places a bet of any amount on a sport event.
2. No Bet Cancellation: Once a bet is placed, it cannot be canceled. The bet remains in effect until the market settlement. However, the CashOut feature provides an alternative for early redemption.
3. CashOut Option: If the player anticipates an unfavorable outcome (e.g., the bet is likely to lose), they can request a CashOut. This action allows the player to reclaim a portion of the bet amount, thereby reducing the potential loss.

Supported Bet Types and Options

• Available Bet Types: CashOut is available for both Single and Combo (Express) bets.
• CashOut Options: Both full and partial CashOuts are supported. Players can choose to withdraw the entire amount offered or only a part of it, leaving the remainder of the bet active.

CashOut Amount Calculation

The amount available for CashOut depends on the real-time change in odds during the sporting event:

• Increase in Winning Probability: If the likelihood of winning increases, the odds decrease, and the CashOut amount increases. For example, if the team on which the bet was placed is performing well, the CashOut value will be higher.
• Decrease in Winning Probability: If the likelihood of winning decreases, the odds increase, and the CashOut amount decreases. For example, if the team from the bet selection is underperforming (plays poorly/doesn't give all their best), the CashOut value will be lower.

In any case, the player, performing a cashout, guarantees the return of funds less than the winning amount, but more in case of losing the bet (to reduce the risk of losing funds in case of loss).

Use Cases

1. Securing Profits: The player can lock in a profit if the bet is in a favorable position, even before the event ends.
2. Minimizing Losses: If the bet is unlikely to succeed, the player can withdraw a portion of the funds to mitigate potential losses.
3. Flexible Bet Management: With partial CashOut, the player can secure part of the winnings or reduce risk, while keeping the rest of the bet active for potential further gains.

Cash-out flow diagram

Bet Delay

Our system allows highly flexible bet delay configuration to optimize both risk management and user experience.

• Per match: Set delays for individual matches.
• Per market: Apply different delays to specific markets within a match.
• Per user group: Tailor delays for different user segments.

This enables tailored delay policies based on the risk profile, popularity, trading conditions of each event or market, or characteristics of user groups. For example, high-profile matches or volatile markets may have longer delays, while low-risk scenarios can have minimal delay.

Combined Delays: How They Work

Some clients prefer to maintain control over bet delays on their own side, applying custom delays according to their risk management policies or operational needs. This setup is fully supported by our platform. While we recommend delegating delay management to DataBet for optimal security and guaranteed results, you are free to implement your own delay logic on your side if desired.

In practice, the delay configured by DataBet is typically shorter than the delays applied by most clients. Our system is designed to minimize latency, leveraging official data sources and real-time trading conditions to keep delays as short as possible. Some of the clients, however, choose to add additional delay on their side for more flexibility over their configuration on their side.

A common misconception is that delays from both the client and DataBet are simply added together (e.g., 6s on the client side + 9s from DataBet = 15s total). This is not correct.

Example Timing Scenarios:

Why Our Delay Is Essential

Clients typically do not have full visibility into real-time trading conditions or data feed health. Our delay mechanism provides a critical safeguard in scenarios like:

• Data Feed Instability: Even during top-tier matches, data feeds can drop or lag unexpectedly. When that happens, our traders may switch to manual handling or immediately suspend the event. To protect market integrity, our system can dynamically increase the delay.
• After-Goal Bets: If the total delay is misconfigured, clients risk accepting "After-goal" bets, when a user places a bet during or right after a major event (e.g., a goal, red card, penalty), but before the market is updated.

Our system ensures this buffer exists — even when the client has applied dynamic or static delay on their end — and thanks to timestamp-based compensation, the user experience is not negatively impacted.

VIP Player Limits

Goal

Prevent misclassification of VIP players and apply correct limits.

Problem

When a new user places their first bet through our Trading Platform, we often lack historical data about their betting behavior. Because of this, the system applies cautious betting limits by default. This can lead to frustration for VIP players who expect higher limits from the outset.

Solution

When integrating our Odds Feed and Managed Trading Services (MTS), sportsbooks often have access to historical user data that can help inform more accurate risk decisions.

A custom maximum payout limit can be passed via the recommended_max_payout field in the initial calculateBet or placeBet API request.

The Trading Platform compares the provided limit with the internal default. If the external limit is higher, it is applied immediately, and the user is assigned to a less restrictive risk group.

⚠️ Important: This mechanism only works for the first calculateBet or placeBet request from a given user. Once the Trading Platform assigns a risk group based on internal models, future partner-provided limits are ignored.

To pass the limit, use the recommended_max_payout parameter — see API documentation.

Examples

• A VIP player making their first bet through a new integration receives a default low limit without partner input. Passing a higher recommended_max_payout ensures their limits reflect their VIP status immediately.
• Partners with existing user data can provide precise limits from the start, improving user experience.

Note: This mechanism exclusively supports increasing the default limit and applies only to a user's initial interaction with the Trading Platform. This feature is optional but highly recommended following the completion of onboarding and the start of bet acceptance.

API endpoints

Detailed swagger documentation

• POST: /bets - notify the platform about a bet being placed on your side. In the response, you will get a bet object if (the bet is successful), or the list of restrictions that aren't met and (the bet's decline), or just an error object if (placing the bet failed).
• DELETE: /bets - notify the trading platform that you have declined the bet that was previously accepted by the trading bet accounting system.
• GET: /restrictions - to retrieve restrictions that can be violated when you try to place a bet with the same parameters.
• POST: /bets/{bet_id}/cash-out-orders/calculate - to calculate cash-out refund amounts for certain bets.
• POST: /bets/{bet_id}/cash-out-orders/place - notify the platform about a cash-out on the bet.
• PATCH: /bets/{bet_id}/cash-out-orders/{cash_out_order_id}/cancel - notify the platform that you have declined the cash-out that was previously accepted by the trading bet accounting system.
• POST: /bets/{bet_id}/cash-out-orders/simplified-calculate - to calculate cash-out refund amounts for certain bets. This api works identically to the regular one, but it allows you to calculate only the full cash-out and does not require additional data in the request body. All you need is the bet ID. A typical use of it is to create a cash-out for a bet in your private back office by a support manager at the request of a player