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.
Feature | Description |
---|---|
Restrictions | Apply conditional restrictions when an account becomes dormant, based on its current restriction. |
Reactivation with last restriction | Decide 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
reason_external_id
This table summarizes how reason_external_id
impacts different financial transactions.
reason_external_id | Debit posting allowed | Credit posting allowed | Forced credit allowed | Forced 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.
Updated about 8 hours ago