1. Why granularity matters in revocation

Blunt revocation — disable the whole account — is often the wrong tool. A fraud signal on one transaction type should not necessarily freeze a customer’s ability to see their statements; an OFAC hit on one counterparty should stop payments to that counterparty, not collapse the entire relationship. Effective suspension has to be as precise as the risk: sometimes the user, sometimes a single operation on a single entity, sometimes everything in between.

2. Today: hierarchy-aware exclusion rules

B5 Secure suspends at two granularities — the whole user, or a specific operation on a specific entity such as an account or contact — and it makes that decision hierarchy-aware. Exclusion rules let a suspension apply at one level while carving out exceptions at another, so “freeze outbound payments on this account, but still allow read and statement download” is expressible directly. The suspension is enforced inside the pipeline, so there is no operation path that bypasses it.

3. The signals that drive suspension

Suspension is the enforcement end of compliance and fraud workflows. Typical triggers are KYC state changes (an unverified or lapsed identity), fraud signals (velocity, device, or rules-engine output), and OFAC / sanctions screening hits on a counterparty. The signal decides the scope; the rule decides the carve-outs; the pipeline enforces the result on the next request.

4. When it takes effect

For new requests, suspension is immediate — the pipeline evaluates it before authorization on every call. The harder problem is already-issued sessions and tokens that were minted before the suspension. Today the exposure is bounded by session and token lifetime; the 2026 extension closes it entirely with Continuous Access Evaluation, which revokes active sessions in near-real-time, and with a versioned policy engine for the rules themselves — both covered in Policy-Driven Suspension & CAE.

5. The calling convention

Suspensions are expressed at the granularity of the risk, with hierarchy-aware exclusions, and enforced by the pipeline.

// Freeze one operation on one entity — keep the rest of the relationship live
suspensions.Apply(new Suspension {
  Subject   = Entity.Account(accountId),
  Operations = Op.PaymentSend,                // only outbound payments
  Exclude    = Op.Read | Op.StatementDownload,  // hierarchy-aware carve-out
  Reason     = Reason.OfacCounterparty
});

// Enforced before authorization on every subsequent request — no bypass path

6. What an attacker actually gets

An account flagged for fraud cannot move money on the next request, even if the attacker holds a valid session, because suspension is evaluated ahead of authorization in the pipeline. The carve-outs mean the legitimate user is not collaterally locked out of benign operations, which keeps support from reflexively handing out blanket re-enablement — a common path back in for the attacker. The remaining seam — a token minted just before the freeze — is what CAE eliminates.

7. Where this lands in an audit

Suspension is the operational control behind sanctions enforcement, fraud response, and access revocation (SOC 2 CC6.2–CC6.3; ISO 27001 A.5.18; plus BSA/OFAC obligations for regulated deployments). The hierarchy-aware model lets you evidence that a freeze was scoped precisely to the risk — neither over- nor under-inclusive — which is exactly the proportionality a regulator examines.

Next: Policy-Driven Suspension & CAE — decisions that reach live sessions →