Korea Loot Box Compliance: Probability Precision, Change Notices, and Pity Systems

Probability-based item compliance in Korea depends on more than publishing a percentage table. The probability applied by the live server, the information displayed in the game, the official website disclosure, and any change notice must remain consistent throughout the product lifecycle.

For game producers, backend engineers, live-operations managers, and compliance teams, this creates a shared technical governance responsibility.

Korea’s Game Industry Promotion Act and its Enforcement Decree establish specific disclosure requirements for probability-based items, including numerical precision, advance notice of changes, multi-stage mechanics, variable probabilities, and pity systems.

The following guide explains the legal requirements and the engineering practices that can help studios reduce operational risk.

1. Probability Precision: What Korea’s Rule Actually Requires

Probability information must generally be displayed as a percentage in a form that users can easily understand.

Korean law does not impose a universal rule requiring every probability to be displayed to exactly four decimal places.

Instead, when rounding is necessary, the probability may be rounded at a decimal place that is at least four positions lower than the first non-zero digit.

For example, if the actual probability is 0.00115%, the first non-zero digit appears in the third decimal place. Displaying the value simply as 0.0012% or 0.0011% would not satisfy the precision standard because both values stop too soon after the first non-zero digit.

Where the rate is finite and can be displayed accurately, the safer approach is to disclose the exact rate, such as:

• Actual probability: 0.00115%
• Accurate display: 0.0011500%

For repeating or highly complex probabilities, the Enforcement Decree also permits fractions, functions, or explanatory text when those methods allow users to understand the probability more easily than a percentage.

Rounding Is Permitted; Truncation Is Not Automatically Safer

The law expressly allows rounding within the prescribed precision standard. It does not establish truncation as the required or universally compliant method.

Blindly truncating a probability can still create an inaccurate disclosure. A displayed rate should be derived from the probability actually applied by the game and calculated according to a documented precision policy.

Engineering Recommendation: Use a Single Source of Truth

A Single Source of Truth, or SSOT, is not itself a statutory requirement. However, it is one of the most effective ways to prevent discrepancies between server logic and public disclosures.

A practical architecture should:

• Store probability weights in a version-controlled source
• Generate server configurations and disclosure tables from the same approved data
• Apply a consistent decimal and rounding policy
• Prevent manual re-entry of probability values
• Validate that the total distribution and individual rates match the intended design
• Preserve the configuration version associated with each live build

Binary floating-point processing is not prohibited, but teams should ensure that conversions do not produce inconsistent server and display values. Fixed-precision decimals, integer weights, or rational representations may provide more predictable results depending on the game architecture.

2. Change Management: Advance Notice and Synchronized Releases

When probability information subject to disclosure is changed, the operator must publish the change details and effective time in advance.

The notice must be posted both:

• In the game; and
• On the game’s official website or another continuously operated official web channel, such as an official blog or social media account

The notice should be published before the changed item becomes available for sale.

Covered changes may include:

• Adding, removing, or replacing obtainable items
• Changing an individual item’s probability
• Changing enhancement success or failure rates
• Changing available bonus-option lists or their probabilities
• Changing fusion results or fusion success rates
• Changing the conditions that affect variable probabilities

If advance notice is genuinely impracticable because of an urgent error correction or another unavoidable reason, the information must be posted without delay after the reason has been resolved.

Is a Before-and-After Comparison Table Mandatory?

The law requires operators to disclose the content and timing of the change. It does not prescribe a universal before-and-after table format.

Nevertheless, a comparison table is a strong compliance practice because it allows users and internal reviewers to identify exactly what changed.

A useful notice may include:

• Item or mechanic name
• Previous probability
• New probability
• Previous obtainable-item list
• New obtainable-item list
• Effective date and time
• Applicable game version
• Reason for the change

Engineering Recommendation: Treat the Update as One Release Unit

Probability configuration, in-game disclosure, website disclosure, and change notices should be managed as one coordinated release.

A safer deployment workflow is:

1. Approve a versioned probability configuration.
2. Generate the in-game and web disclosure data from that configuration.
3. Compare the server values, UI strings, and website table in a staging environment.
4. Publish the required advance notice.
5. Activate the new configuration at the announced time.
6. Verify the live service immediately after deployment.
7. Preserve the approved data, notice, screenshots, and deployment logs.

Automating this workflow through JSON, XML, or an internal API is not legally required. It is a compliance-by-design measure that reduces manual copying errors and publication delays.

3. Multi-Stage and Composite Probability Systems

Korean rules distinguish among several types of probability-based items, including capsule-type, enhancement-type, and composition-type systems.

If one mechanic falls within more than one category, the disclosure requirements applicable to each category must be considered.

For a composition-type system, operators generally need to disclose the probability of each result produced by the random fusion or combination.

For example, consider the following process:

1. A paid Box A randomly provides materials.
2. The materials are combined through a random fusion system.
3. The fusion produces Item C or another possible result.

If both the box-opening stage and fusion stage independently qualify as regulated probability-based mechanics, the applicable probability information for both stages should be disclosed.

A deterministic stage does not become probabilistic merely because it follows a loot box. Each stage should be reviewed according to how the user acquires the inputs, whether a paid item is involved, and whether the outcome is determined by chance.

4. Dynamic Probabilities and Escalating Rates

Some probability systems change according to the user’s gameplay progress, purchase history, number of attempts, owned items, previous failures, or other conditions.

When the applied probability changes according to such conditions, the disclosure should explain:

• The condition that changes the probability
• The probability applied before the condition is met
• The changed probability
• The point at which the change takes effect
• Whether the rate resets and, if so, when
• Any conditions that suspend or remove the adjustment

Examples include:

• An increased enhancement rate after a failed attempt
• An escalating character-acquisition rate after repeated pulls
• A probability adjustment based on a particular item owned by the user
• A wishlist or selected-character system that changes the composition of the pool

A single static probability may be insufficient when different users or different attempts receive materially different rates.

5. Pity Systems and Guaranteed Rewards

A pity system guarantees a result after a user completes a specified number of purchases, openings, enhancement attempts, or combinations.

For these systems, the operator should disclose the condition required to trigger the guarantee.

The disclosure should identify:

• The number of attempts required
• The items obtainable through the guarantee
• The probability applicable to each obtainable item
• The probability applied at each attempt when the rate changes by attempt
• Any reset, carry-over, banner-transfer, or expiration condition that affects progress

If the rate remains constant until the guaranteed attempt, that structure should be stated clearly. If the probability increases at defined thresholds, the applicable rates should be disclosed in a way users can understand.

The law does not require one specific visual format. Depending on the mechanic, the information may be presented through a percentage table, attempt-by-attempt schedule, formula, function, or explanatory text.

The key requirement is that the disclosure accurately communicates the probability and the conditions that affect the result.

6. Building a Defensible Probability Governance System

A reliable compliance system should connect the game’s design, engineering, QA, live operations, publishing, customer support, and regulatory-response teams.

At minimum, studios should maintain:

• A complete inventory of regulated probability-based mechanics
• An owner for each probability table
• Version-controlled probability configurations
• A documented precision and rounding policy
• Pre-release server-to-display validation
• A formal approval process for probability changes
• Advance-notice templates and publication checklists
• Screenshots showing the in-game disclosure location
• Searchable website probability tables
• Documentation of pity, wishlist, fusion, and dynamic weighting logic
• Historical records of previous configurations and notices

Website disclosures should be presented as searchable text or numerical data rather than image-only tables. If the volume of information makes direct in-game display impracticable, the game may provide a direct link to the relevant website disclosure page in accordance with the applicable requirements.

Technical Governance as a Compliance Advantage

Probability disclosure is not simply a final legal review conducted after development. It is a continuing operational obligation that should be reflected in the game’s data architecture and release process.

A studio that generates server configurations, public disclosures, change notices, and verification evidence from the same controlled source can respond faster to user complaints and regulatory inquiries.

For related enforcement and consumer-risk considerations, see Korea’s Zero-Tolerance Era: Why Probability Errors Are Now Business-Critical.

TheGameAgent supports global game developers and publishers with probability disclosure reviews, technical compliance assessments, evidence preparation, Korean regulatory communication, and corrective-action coordination.

Transparent probability systems do more than reduce regulatory risk. They also strengthen player trust and make live operations more resilient.

‍