> For the complete documentation index, see [llms.txt](https://docs.sportradar.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sportradar.com/mts/features/cashout-engine.md). # Cashout Engine The Cashout Engine enables operators to offer bettors the option to settle eligible bets before the event has ended. Depending on the current event and market state, the cash-out value may be higher or lower than the original stake. The engine supports the full cash-out lifecycle: * calculating current cash-out values; * applying operator-configured margins and risk rules; * validating a requested cash-out; * executing or reporting the cash-out; * monitoring conditions for automatic cash-out. Operators can choose how much of the calculation, validation, and execution process they want MTS to manage. ### Cashout Engine capabilities | Capability | What it does | Who controls the final cash-out decision | | ---------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------- | | `cashout-build` | Returns current cash-out values and supporting risk information | The operator or MTS, according to the configured validation strategy | | `cashout-build-subscription` | Delivers updated cash-out build values asynchronously while a subscription is active | The operator or MTS, according to the configured validation strategy | | `cashout-placement` | Validates and finalises a cash-out request through MTS | MTS, according to the configured validation strategy | | `cashout-inform` | Reports a cash-out that the operator has already executed | The operator | | `auto-cashout` | Monitors a bettor-defined threshold and notifies the operator when it is fulfilled | The operator completes the configured finalisation flow | `cashout-build` and `cashout-build-subscription` provide cash-out information. They do not execute a payout. `cashout-placement` and `cashout-inform` are finalisation operations: * use `cashout-placement` when MTS should validate the cash-out before it is completed; * use `cashout-inform` when the operator calculates, validates, and executes the cash-out locally and then reports it to MTS. ### Cash-out lifecycle A typical managed cash-out flow is: ```mermaid flowchart TD A[Cashout build] --> B[Bettor accepts the offer] B --> C[Cashout placement] C --> D[Accepted placement] D --> E[Operator completes the local payout] ``` For an operator-controlled flow: ```mermaid flowchart TD A[Operator calculates and validates the cash-out] --> B[Operator completes the local payout] B --> C[Cashout inform] ``` An accepted `cashout-placement` completes the MTS-managed cash-out flow. A subsequent `cashout-inform` is not required for the same cash-out. ### Cashout Build `cashout-build` provides a current cash-out calculation and supporting information for an eligible ticket or bet. Depending on the ticket and configuration, the response can include: * fair cash-out value; * margin-adjusted cash-out value; * maximum potential payout; * bettor-related risk information; * event and market information; * recommended live-time-delay information; * settlement and partial-cash-out information. Operators can use the result to: * display an offer to the bettor; * enrich their own cash-out logic; * validate an internally calculated amount; * use the result as the basis for a later `cashout-placement` request; * use the result before sending `cashout-inform`. A build result is a point-in-time calculation. It is not a reservation or a guarantee that the value will remain available when the bettor accepts the offer. ### Cashout Build Subscription `cashout-build-subscription` provides asynchronous updates for the cash-out value of a ticket or bet. The operator creates a subscription for an eligible target. MTS then recalculates the cash-out value when relevant event, market, probability, settlement, or other cash-out state changes occur and sends updated build results to the operator. This is intended for clients that want push-based updates instead of repeatedly polling with `cashout-build`. A subscription: * can produce more than one build result; * remains active for a limited period; * does not reserve a cash-out value; * does not execute a payout; * must still be followed by `cashout-placement` or `cashout-inform` when the cash-out is to be completed. The current implementation supports a five-minute subscription lifetime unless the subscription ends earlier because the target reaches a terminal state or an explicitly supported termination mechanism is used. `cashout-build-subscription` is different from Auto Cashout: * a build subscription sends updated cash-out values; * Auto Cashout monitors a configured threshold and notifies the operator when the threshold is fulfilled. ### Cashout Placement `cashout-placement` submits a cash-out for final validation by MTS. MTS validates the request against the current ticket, bettor, event, market, settlement, and operator configuration. Depending on the operator setup, validation can use: * fair cash-out value; or * a margin-adjusted cash-out value. MTS can also apply the configured live-time-delay and revalidate the relevant ticket and market state before returning the final decision. The operator receives an accepted or rejected result: * if accepted, the operator completes the local payout using the accepted result; * if rejected, the operator must not pay the bettor based only on an earlier build result. This operation is intended for operators that want MTS to own the final cash-out risk decision while retaining control over their bettor-facing interface. ### Cashout Inform `cashout-inform` is used when the operator controls the cash-out calculation, validation, and execution. The operator: 1. calculates the cash-out value; 2. presents the offer to the bettor; 3. executes the cash-out locally after acceptance; 4. informs MTS of the completed cash-out. MTS performs basic validation and updates the relevant cash-out, liability, and reporting information. This operation does not provide the same risk-managed validation as `cashout-placement`. `cashout-inform` can also be used for tickets or content that are not eligible for managed cash-out through `cashout-build` and `cashout-placement`, subject to the applicable validation and operator configuration. ### Auto Cashout `auto-cashout` allows a bettor or operator to define a threshold that should trigger a cash-out action automatically. The current MVP supports: * take-win thresholds; * one threshold per request; * full-ticket auto cash-out; * full-bet auto cash-out; * recalculation when relevant event or market changes occur; * asynchronous notification when the configured condition is fulfilled. A fulfilled Auto Cashout condition is a cash-out suggestion or notification. It is not, by itself, confirmation that the cash-out has been completed. The operator must complete the configured finalisation flow after receiving the notification. The recommendation is to complete the cash-out locally and send `cashout-inform` to MTS for finalisation. In case of auto cashout, `cashout-placement` is not mandatory since the initial risk management will be done on the auto cashout request, including in-play delay, bettor profile and market status checks. Additional capabilities, including stop-loss, multiple thresholds, partial Auto Cashouts, wallet integration, and REST-based validation of existing Auto Cashouts, depend on the applicable product version and rollout status. ### Operator integration models Operators can choose from several integration models. #### Operator-controlled cash-out ``` cashout-inform ``` The operator owns calculation, validation, user experience, and payout execution. MTS receives the result for liability and reporting purposes. #### Operator-controlled calculation with MTS data ``` cashout-build → cashout-inform ``` The operator uses MTS cash-out values, profiles, market information, or live-time-delay recommendations to enrich its own logic. The operator still controls validation and execution. #### MTS validation using fair value ``` cashout-placement ``` The operator controls the bettor-facing offer, while MTS validates the submitted value using the configured fair-value strategy. #### Full-risk delegation ``` cashout-build → cashout-placement ``` The operator uses the margin-adjusted value returned by `cashout-build`, displays it to the bettor, and submits the accepted value through `cashout-placement`. MTS performs the final risk validation and, when accepted, the operator completes the local payout. #### Asynchronous build updates ``` cashout-build-subscription → cashout-placement or cashout-inform ``` The operator subscribes to updates instead of polling for every new build calculation. The latest build value can then be displayed or used as the basis for the applicable finalisation flow. ### Cash-out scope Subject to ticket eligibility and operator configuration, the Cashout Engine supports: * full-ticket cash-outs; * partial-ticket cash-outs; * full-bet cash-outs; * partial-bet cash-outs. A cash-out request targets a ticket or a complete bet. It does not target individual selections or legs inside an accumulator. One complete independent bet can be cashed out while other bets on the same ticket remain open. However, an unsupported selection or accumulator leg can make the affected bet, or the complete ticket, ineligible for managed cash-out. Ticket-level and bet-level cash-out approaches must not be mixed on the same ticket. ### Risk management and configurable value The Cashout Engine can calculate and validate cash-out values using information from several areas, including: * current probabilities; * event and market state; * settlement state; * bettor profile and risk indicators; * live-time-delay rules; * operator-configured margin settings. The margin-adjusted cash-out is intended to help operators balance bettor value and profitability. Operators can configure their cash-out strategy according to factors such as event, market, bettor segment, and pre-match or live state. MTS can apply the configured validation strategy during `cashout-placement` and reject a request when the submitted value is no longer valid or the ticket is no longer eligible. ### Supported content and eligibility Cash-out availability depends on: * the sport, event, market, and selection coverage; * whether MTS manages the relevant event and content; * the ticket and bet construction; * the operator configuration; * the currency and ticket identity used in the request; * whether the ticket has already been cancelled or cashed out; * whether the ticket contains external or mixed-provider content. Acceptance of the original ticket placement does not by itself guarantee eligibility for a later managed cash-out. Managed cash-out is currently intended for MTS-managed content, including content supplied through OneFeed. Full or mixed external tickets may not support `cashout-build` and `cashout-placement`, but may remain eligible for `cashout-inform` when the operator performs the cash-out locally. ### Operational considerations Cash-out values can change as event, market, probability, settlement, and live-delay states change. Operators should: * display the latest available build value; * avoid treating a build result as a guaranteed quote; * handle placement rejection when the ticket or market state changes; * prevent duplicate cash-out actions while placement is being processed; * use cumulative values for successive partial cash-outs; * use the same supported currency as the original ticket; * confirm enabled operations and limits for each environment and operator profile. **See also:** [Cash-out Description and Flow](/transaction30api/api-description/ticket-json-format-description/cash-out-description-and-flow.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.sportradar.com/mts/features/cashout-engine.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.