Continued
The advantage of Net Pool Pricing is tracks need not alter their takeout and distribution of revenues to suit another jurisdiction’s takeout percentage.
Disadvantages are slightly different prices in various jurisdictions and display issues, including conflicting odds for the same race/pool. In the case of account wagering, these price variances potentially could lead to “odds shopping” by bettors.
Another noticeable disadvantage is the expansion of negative breaks in Place and Show
pools, as the payout pool is divided prior to calculation of the payout price. Also, low takeout customers may subsidize the payouts of high-takeout customers in a common net pool.
Regardless of differing takeout rates, net pool pricing is the most common method for parimutuel pool calculations used in North America.
C. System Dependent Procedures -Common Pool Wagering
Smooth operation of the simulcast requires the Host track to know what totalisator systems are being employed by Guest sites. Most North American racetracks are using ITSP 5.18 and 5.19 versions.
i. Setup
• The Guest selects a particular track and/or race.
• Guest links up with Host via modem or frame relay.
• Host and Guest synchronize their respective totalisator clock settings by
referencing standardized universal time as a daily guide; ITSP 5.18 and later
versions will inform if time discrepancies exist.
• Guest's access to the system must be verified and double checked, by assigning
daily entry codes to Guest sites and identifying the key personnel involved.
• Guest initializes event configuration on tote system by either downloading live
runners/morning line and wagering pools from the Host System or by inputting that
information directly into its system.
• ITSP 5.18 (and subsequent versions):
-Verifies pool definitions and live runners,
-Enables Host to identify (log) any discrepancy in minimum wager values for
all bet types and alert the Guest,
-Transmits to Guest Systems any scratches,
-Supports tote reconcilable data through the TRA Settlement File (See page
5.3) from individual pari-mutuel facilities wagering through a tote hub.
-Generates and transports settlement files to host.
• Scratches and refunding procedures can also be initiated manually by Guest.
• Host transmits late mutuel changes, such as the elimination or addition of a pool.
.
The advantage of Net Pool Pricing is tracks need not alter their takeout and distribution of revenues to suit another jurisdiction’s takeout percentage.
Disadvantages are slightly different prices in various jurisdictions and display issues, including conflicting odds for the same race/pool. In the case of account wagering, these price variances potentially could lead to “odds shopping” by bettors.
Another noticeable disadvantage is the expansion of negative breaks in Place and Show
pools, as the payout pool is divided prior to calculation of the payout price. Also, low takeout customers may subsidize the payouts of high-takeout customers in a common net pool.
Regardless of differing takeout rates, net pool pricing is the most common method for parimutuel pool calculations used in North America.
C. System Dependent Procedures -Common Pool Wagering
Smooth operation of the simulcast requires the Host track to know what totalisator systems are being employed by Guest sites. Most North American racetracks are using ITSP 5.18 and 5.19 versions.
i. Setup
• The Guest selects a particular track and/or race.
• Guest links up with Host via modem or frame relay.
• Host and Guest synchronize their respective totalisator clock settings by
referencing standardized universal time as a daily guide; ITSP 5.18 and later
versions will inform if time discrepancies exist.
• Guest's access to the system must be verified and double checked, by assigning
daily entry codes to Guest sites and identifying the key personnel involved.
• Guest initializes event configuration on tote system by either downloading live
runners/morning line and wagering pools from the Host System or by inputting that
information directly into its system.
• ITSP 5.18 (and subsequent versions):
-Verifies pool definitions and live runners,
-Enables Host to identify (log) any discrepancy in minimum wager values for
all bet types and alert the Guest,
-Transmits to Guest Systems any scratches,
-Supports tote reconcilable data through the TRA Settlement File (See page
5.3) from individual pari-mutuel facilities wagering through a tote hub.
-Generates and transports settlement files to host.
• Scratches and refunding procedures can also be initiated manually by Guest.
• Host transmits late mutuel changes, such as the elimination or addition of a pool.
.
