Dirty Pool Stops Assignment Instead of Swapping in Silence

When a JIT request encounters a compromised number pool, silently swapping the asset behind the scenes is a dangerous trap that breaks webhook synchronization and DLR tracking. The correct fix is to halt the assignment pipeline immediately. This article explains how the IOSOR platform detects dirty pools and manages the process safely using a dedicated internal state.

The Mechanics of Dirty Pool Detection

When a JIT (Just-In-Time) request for an E.164 number is initiated, the IOSOR platform evaluates the target pool's health metrics. If inbound SMS spam, high volumes of unhandled STOP keywords, or dead OTP delivery patterns are detected, the pool is flagged as dirty. Instead of assigning a compromised number to an active account, the system halts the assignment pipeline.

Why Silent Swapping is a Platform Risk

Silently swapping a number to hide a bad pool creates severe downstream synchronization issues. If a buyer requests a specific E.164 asset and receives a silent swap, their webhook endpoints get confused, and DLR tracking breaks. We do not present a fake Activated status to the client console. Faking success while swapping assets in the background leads to API mismatch errors and corrupts the ledger.

The Needs_Swap State and Ops Console Visibility

To handle dirty pools safely, the internal system marks the transaction with a 'Needs_swap' state. This specific language remains strictly ops-side to prevent client-facing confusion. The buyer sees a clean 'Pending' or 'Paused' state in their dashboard. This prevents false expectations while platform operators manually inspect the pool or rotate the underlying routing paths. The buyer's API receives a structured pause notification rather than a simulated success message.

Ledger Holds and the Prepaid Floor

During this assignment pause, the prepaid hold on the buyer's balance remains active but uncaptured. If the account balance drops below the required USD 20 prepaid floor, the assignment is automatically rejected to prevent overdrafts. For high-volume accounts approaching the soft review near USD 1,000/month, this pause prevents runaway MRC (Monthly Recurring Charge) accumulation on bad assets. Once the pool is cleared or swapped by ops, the ledger hold is finalized.

Resolving Blocked Assignments and Related Incidents

Resolving these blocked assignments requires systematic verification of the pool's health. Operators must review the routing logs and confirm that inbound SMS and OTP flows are clean before releasing the hold.

Related: Cool-down before a number pool is reused · Number Aging is Reputation, Not a JIT Buy · Prepaid hold before first debit.

Start with IOSOR

To resolve a blocked assignment, open the IOSOR Ops Console and locate the flagged JIT transaction currently held in the 'Needs_swap' state. Verify that the buyer-facing dashboard correctly displays a 'Paused' status rather than a deceptive 'Activated' state, which would otherwise corrupt their webhook endpoints and DLR tracking. Once the dirty pool metrics are cleared or a manual swap is approved, release the ledger hold to resume normal routing.

IOSOR takeaway

This article proved that masking dirty pool issues with silent number swaps is a critical platform risk that breaks downstream API synchronization. By keeping the 'Needs_swap' flag strictly on the ops-side and showing buyers a transparent pause, IOSOR prevents webhook confusion and maintains ledger integrity.

Do not attempt to bypass dirty pool flags by forcing a fake 'Activated' status to the client dashboard. Instead, always allow the system to hold the transaction in a paused state until the pool's health metrics are verified and the routing logs are cleared.