A sub-account cap hit is a hard stop, not a silent overflow

Hitting a sub-account cap in IOSOR acts as a strict halt rather than draining the main balance. This prevents surprise costs when dispatching SMS or OTP traffic. You can easily clear the block by raising limits via API.

Understanding the hard ceiling logic

In the IOSOR architecture, sub-account limits are enforced as hard stops. When a specific department or brand reaches its allocated quota, the system triggers an immediate pause on all outbound SMS and OTP requests. This is a deliberate design choice to ensure financial predictability for white-label partners. Unlike legacy systems that might allow a silent overflow into the parent wallet, IOSOR requires explicit manual intervention or automated API triggers to adjust caps. This prevents unexpected billing spikes at the end of a cycle.

Why silent parent borrowing is disabled

Silent borrowing creates a lack of accountability for individual sub-entities. In our white-label environment, if a sub-account hits its MRC or daily volume cap, the DLR status will reflect a STOP or rejected state. The webhook will notify your primary console immediately. This isolation ensures that one compromised sub-account cannot drain the entire master balance. JIT number assignment remains active for other sub-accounts, but the capped entity is effectively frozen until the ledger is refreshed or the cap is raised.

Managing the USD 20 prepaid floor

To maintain active status, each sub-account or the master wallet must respect the USD 20 prepaid floor. This minimum balance ensures that JIT provisioning and initial SMS bursts are processed without latency. When the balance drops below this floor, the system may preemptively pause traffic to avoid negative balances. This is not an overflow; it is a safety mechanism. You can monitor these levels via the dashboard or set up automated alerts to trigger before the hard stop occurs.

Scaling past the USD 1,000 soft review

As your volume grows, IOSOR implements a soft review once a sub-account or master entity approaches a monthly spend of USD 1,000. This is a standard procedure to ensure traffic quality and compliance with global routing standards. During this review, we examine DLR patterns and OTP conversion rates. It is not a hard block, but a verification step to move into higher throughput tiers. Once cleared, your sub-accounts can handle significantly higher concurrent loads without the risk of being flagged by automated anti-spam filters.

Critical links for volume management

Managing traffic requires understanding how the system handles queues and suppressions.

Related: Brand spend caps before production send · Department Sub-accounts vs White-label Tenants · Prepaid hold before first debit.

Start with IOSOR

Navigate to your IOSOR console sub-account controls to configure webhook alerts for sub-account quota thresholds before a hard stop occurs. If a department reaches its ceiling, review the blocked DLR events rather than assuming traffic automatically failed over to the master account. You can manually adjust the quota cap or approve a dedicated sub-account credit top-up directly within the governance tab to resume dispatch.

IOSOR takeaway

A sub-account hitting its ceiling must trigger an immediate pause rather than silently leeching credits or volume allowances from the parent entity. Isolating departmental limits ensures strict financial accountability, predictable routing metrics, and transparent sub-account delivery reporting across all active brand instances.

Do monitor threshold webhooks and configure automated escalation alerts when a sub-account reaches 90% of its monthly or daily volume cap. Don't expect parent-level fallbacks to silently absorb overflow, as this masks operational overruns and compromises individual brand audit trails.