Restriction management

The Dormancy feature includes enhanced restriction management capabilities, giving you greater flexibility and control over how account restrictions are applied when accounts transition into and out of dormant status.

These improvements enable you to define rules that adapt restrictions based on an account’s existing state, control how restrictions behave during reactivation, and ensure that transactions and dormancy checks follow your operational and compliance requirements.

Advanced restriction management includes the following features.

FeatureDescription
RestrictionsApply conditional restrictions when an account becomes dormant, based on its current restriction.
Reactivation with last restrictionDecide whether an account should retain its last restriction upon reactivation.

These improvements make restriction handling more context‑aware and customizable, reducing the need for manual intervention and helping ensure compliance with business rules across different regions and operational scenarios. For details, refer to Create dormancy configuration.

These subsections describe each capability in detail, explain how it works, and provide examples for implementation.

Restrictions

The statuses field in the Create dormancy configuration endpoint is an array of status objects that you use to define the statuses related to dormancy. Each status object contains a restrictions array field that allows you to define conditional logic that is applied when the account status changes to DORMANT.

The Pismo platform checks the account’s current restriction using the field current_reason_external_id.
If a matching condition is found in the restrictions array, the account is assigned the corresponding new_reason_external_id when it becomes dormant. If no condition matches, the account receives the default restriction defined by reason_external_id.

Example

Default behavior

After 30 days of inactivity, an account transitions to DORMANT with the restriction reason_external_id = CREDIT_ONLY.

Conditional override

If an account is NORMAL and restricted as DEBIT_ONLY, you can configure the system so that when it becomes DORMANT, it receives NONE instead of the default CREDIT_ONLY.

💡

Note

You can add as many restrictions as necessary to meet your business needs.

Impact of reason_external_id

This table summarizes how reason_external_id impacts different financial transactions.

reason_external_idDebit posting allowedCredit posting allowedForced credit allowedForced debit allowed
DEBIT_ONLY
CREDIT_ONLY
ALL
NONE
CREDIT_ONLY_NO_FORCE_DEBIT_ALLOWED
DEBIT_ONLY_NO_FORCE_CREDIT_ALLOWED
ALL_NO_FORCE_ALLOWED
NONE_NO_FORCE_ALLOWED
FORCE_CREDIT_ONLY
FORCE_DEBIT_ONLY

Reactivation with last restriction

The reactivation_with_last_restriction field allows you to control whether an account, once reactivated from a dormant status, must retain the restriction it had before becoming dormant.

If you set reactivation_with_last_restriction to true, the account returns to NORMAL status with the same restriction it had before dormancy; otherwise, the account is reactivated without any previous restrictions, unless another rule applies.

Example

If an account was NORMAL with a restriction of DEBIT_ONLY before becoming DORMANT, setting reactivation_with_last_restriction = true ensures it returns to NORMAL with DEBIT_ONLY after reactivation.