HUBCHANGE logo

SEJAM trading restriction explained: what happened and the practical RWA lesson

7 min read

A real market just offered a clear identity-enforcement lesson: restrictions are rarely “all or nothing.” They are usually staged, specific to actions, and paired with a path back to full access.

A real market just offered a clear identity-enforcement lesson: restrictions are rarely “all or nothing.” They are usually staged, specific to actions, and paired with a path back to full access. For teams designing RWA (real-world asset) distribution, that is not a legal footnote—it is a product capability.

What happened?

Reports in Iranian media said trading restrictions would apply to market participants who lack SEJAM registration/verification. In re-publications of the news, a deadline was stated as 31 Shahrivar 1405 (22 Sep 2026). Beyond that, the public reporting does not provide a complete, operationally granular matrix of exactly which actions are restricted in which order.

That limitation is important for how we read the event: we can treat the verified fact as “identity status is being tied to trading permissions at scale,” and treat the rest as a design prompt—how we would implement the same idea responsibly in an RWA product without breaking user experience.

Why does it matter?

Identity enforcement at market scale has two practical implications:

  1. Eligibility becomes enforceable only when it is encoded in system behavior. Policies and terms matter, but enforcement happens at the moment a user tries to place an order, transfer a unit, or withdraw.

  2. The safest operational approach is staged restrictions. Sudden hard blocks can trap users in partially completed processes (pending settlements, mismatched balances, customer support disputes). Staged controls let us reduce risk while keeping the system coherent.

For RWA teams, this is the core insight: the most usable compliance is the one that is explicit, gradual, and reversible.

What it means for RWA and tokenization

RWA here means asset-backed units (often tokenized) whose ownership and transfers are represented digitally. Tokenization can make holding and transferring these units more traceable and programmable; its strongest results come when identity verification and operating controls are designed alongside it.

In practice, “identity not completed” is not a single state. It is a spectrum:

  • user started verification but is pending
  • user is missing required identity attributes
  • user failed verification
  • user was previously verified but needs re-check

If we compress all of that into “blocked,” we lose control. The better approach is to map identity status to action-level permissions.

What exactly can be restricted (and why action-level matters)

In asset-backed unit flows, we usually have a handful of user actions. Even if the underlying rails differ (brokerage, fund units, on-chain transfers, off-chain registry), the product surface looks similar:

  • Buy / subscribe: creating exposure and increasing position
  • Sell / redeem: reducing exposure and exiting
  • Transfer: moving units to another account/wallet
  • Withdraw: moving cash/fiat out (or stable-value equivalents)
  • Deposit: bringing value in (often lower risk than withdrawals)

The key design move is to define restrictions per action, not as a vague “account frozen.” For example:

  • We may pause buy first (prevents new exposure) while allowing limited sell to avoid trapping users.
  • We may restrict transfer before restricting sell, because transfers can bypass internal checks and complicate audit trails.
  • We may keep deposit open while restricting withdraw, because the risk profiles differ.

This is not a universal rule; it is a structured way to think.

A practical framework: Warn → Grace → Soft restrict → Hard restrict → Resume

Below is a reusable “eligibility gating” ladder that RWA teams can adapt. It keeps enforcement predictable while preserving a clear path to restore access.

1) Warn (clear messaging)

We announce the eligibility requirement early and repeatedly in product surfaces that match the behavior: trading screens, transfer screens, and the portfolio page. The message works best when it answers three questions:

  • what is changing
  • when it changes (deadline)
  • what to do to avoid restrictions

2) Grace period (time to complete identity)

A grace period reduces support load and panic behavior. It also lets us measure where users get stuck in the identity flow (drop-offs, document errors, verification delays).

3) Soft restriction (risk reduction without breaking the system)

Soft restrictions aim to stop riskier growth actions while preserving safe exits and operational cleanup. Typical soft controls include:

  • disallow buy / subscribe
  • cap order sizes or number of daily actions
  • disallow transfers to new destinations while allowing internal reconciliation

4) Hard restriction (only when needed)

Hard restrictions are used when the deadline passes or risk thresholds are triggered. Examples:

  • block new orders entirely
  • block transfers and withdrawals
  • allow only actions that resolve existing obligations (for example, settling already-matched trades), if applicable to the system design

5) Resume (fast unblocking with proof)

Resumption must be designed as carefully as restriction. We need:

  • a clear checklist of what identity step is missing
  • predictable review times (even if only an estimate)
  • immediate permission updates once verification is completed

The product lesson from market-wide enforcement is simple: restrictions are tolerable when the unblocking path is obvious.

What could this mean for the Iranian market?

At a high level, tying trading permissions to SEJAM status signals a push toward consistent identity coverage in market participation. For product and operations teams, the practical effect is that identity status becomes a first-class field in transaction authorization.

For RWA distribution flows, this suggests we should treat eligibility as a system primitive:

  • enforceable at the moment of action
  • explainable to users
  • auditable for disputes

This is how we keep tokenization’s programmability aligned with real-world compliance expectations.

What to watch next

Because public reporting may not fully specify the operational scope, what matters next is what gets clarified in practice. In similar enforcement events, we typically monitor:

  • Scope: which instruments/units are included and which actions are affected
  • Order of enforcement: what gets restricted first (buy, transfer, withdraw, etc.)
  • Unblocking flow: how quickly permissions are restored after verification
  • Behavioral effects: completion rates for identity, trading volume shifts, support ticket spikes

For RWA teams, these are also the same metrics we would use to tune our own restriction ladder.

Implementation notes (non-legal): logs, messaging, auditability

Even at an introductory level, a few implementation habits make staged restrictions safer:

  • Event logs: record every restriction decision as an event (who, when, which rule, which action was blocked/allowed). This is invaluable for later audits and dispute handling.
  • User messaging tied to action: show the restriction reason at the moment of attempted action, not only in a generic notification.
  • Deterministic rules: prefer clear rule tables over ad-hoc manual decisions, while still allowing an exception process.
  • Monitoring: track where users fail verification and shorten that path before tightening restrictions.

None of the above is legal advice. It is product and operational design that helps compliance requirements become executable.

Conclusion

The reported SEJAM-related restriction news is a timely reminder that identity enforcement becomes workable when it is staged, explicit by action type, and paired with a clear restoration path.

For RWA and asset-backed unit products, the reusable lesson is to treat “eligibility” as a product capability: define permissions per action (buy/sell/transfer/withdraw), roll restrictions out in steps, and log every decision so the system remains explainable and auditable.

FAQ

1) Does this news mean every RWA product must copy the exact same restrictions?
No. The verified takeaway is the pattern of enforcement (identity-linked permissions), not a universal rulebook. Each product adapts the ladder to its own risk and operating model.

2) Why not just block the whole account when identity is incomplete?
Because full blocks can create operational dead-ends (pending settlements, reconciliation issues) and increase disputes. Action-level restrictions keep control while preserving safe exits.

3) What is the simplest “first version” of eligibility gating?
Start with two stages: (a) warn + grace period, then (b) block buy and transfers while keeping a clear identity-completion path and an auditable log of decisions.

Sources