The Pismo platform allows you to designate an account as dormant if it has remained inactive for an extended period. It features an API that enables you to set dormancy rules, which govern account reactivation conditions and status changes.

Dormancy pertains to bank accounts that show no financial activity over an extended duration. Banks monitor dormant accounts closely due to their susceptibility to internal fraud. Dormant accounts are also vulnerable to fund siphoning due to lack of attention from the account holder. Regulators in many countries stipulate rules for dormancy, and banks can usually establish their own reactivation rules, to mitigate operational and fraud risks. Banks typically transition an account through an inactive phase before moving to dormancy. A customer-initiated transaction, such as a fund transfer, check payment, or ATM cash withdrawal, can prevent an inactive account from entering dormancy.

Following dormancy, an account might enter UNCLAIMED status, prompting its closure and transfer of its funds to a central bank. Transactions on dormant accounts are restricted to bank-initiated activities only ( unlike a total account blockage).

If a dormant account can be reactivated, a bank can opt to do this manually or allow a customer-initiated debit or credit transaction to reactivate the account.

Configure dormancy

The Pismo platform's dormancy feature evaluates various factors to determine whether an account's status must be changed. To begin configuring dormancy, consider the following questions:

• What is the level of the dormancy configuration — is it at the program level or division level? If dormancy configurations exist at both levels, they must adhere to the hierarchy described in Dormancy inheritance. One thing to remember is that setting a dormancy configuration at the account level is not possible.
• What time of day should the platform check the dormancy status of the account? Note that the timezone setting for dormancy check is inherited from the division or program. For more information, see Account status-check schedule.
• How many statuses do you need to define for the account? You can define as many statuses as you want (minimum of one) and specify their order.
• How many days can an account remain in each status? Additionally, you must determine the number of days an account can remain without any transactions to trigger a status change. For example:
  • Dormant (3 days); Inactive (5 days)
  • Inactive (3 days); Dormant (5 days); Unclaimed (30 days)
  • Unclaimed (45 days)
• Which processing codes (if any) can reactivate a dormant account?

Once you have these answers, use the Create dormancy configuration endpoint to set up dormancy configurations.

Account status-check schedule

The Pismo platform verifies the account's correct status only during scheduled checks, which are initiated by one of the following triggers:

• Account created under a program or division that is already configured for dormancy.
• Creation of a dormancy configuration for a division or program with existing accounts.
• When a transaction occurs in an account belonging to a program or division with dormancy configuration, excluding transactions designated to skip based on defined processing codes, the previous schedule is deleted and replaced with a new one.
• Change in account status, either by the dormancy configuration or manually.

The scheduling process always follows the following logic: inactive since + # days until the next dormancy state. When a trigger occurs, the Pismo platform evaluates the next account status and determines the number of days until the status changes.

Dormancy metrics

To understand dormancy metrics, note the following:

• Inactivity_time is the number of days the account has remained inactive. It is the difference between the current date/time (UTC) minus the inactive_since date/time.
• Inactivity_time is the duration, in days, during which the account has remained inactive. Inactivity_time is calculated as the difference between the current date and time in UTC and the inactive_since timestamp.
• Inactive_since: is the date/time of the most recent account activity. If a new dormancy configuration is established, for existing accounts, inactive_since equals the date/time of dormancy configuration creation until the occurrence of the subsequent transaction. However, if the account is opened subsequent to the creation of the dormancy configuration, inactive_since refers to the account's creation time until the occurrence of the next transaction.

Account status change

When a transaction occurs that is allowed to reactivate a dormant account, the platform restores the account status to NORMAL. When the criteria are met to change an account status to inactive, the platform automatically transitions the account to the next status. When an account moves to another program or division with a different dormancy configuration, it retains its current status.

Skip processing codes

Some transactions, such interest accruals, charges, and taxes, are not considered customer-initiated transactions. These transactions do not affect the calculation of dormancy based on account inactivity.

To specify which transactions can reactivate a dormant account or reset the inactivity counter, you specify the relevant processing codes when creating or updating the dormancy configuration. Use List processing codes to retrieve a list of available processing codes. For more information about processing codes, see Standard processing codes and Processing codes and transaction types.

Regardless of account status, when a transaction with a disallowed processing code occurs, the inactive_since date remains unchanged. As a result, inactivity_time does not reset, and the transaction is not factored into the dormancy calculation.

Account status reason ID

You can configure account status reasons to explain why an account status was changed. Reasons are represented by numerical IDs (reason_id). They are optionally associated with statuses. They also can be used to override account status restrictions for debits and credits. Each account status can link to only one reason ID, and each account can have only one combination of reason ID and account status. For instance, the status NORMAL typically has the reason ANY, indicating that any transaction is permitted, including force operations.

To see a list of account status reason IDs, use List account status reasons.

Reason IDs include the following types:

For information about statuses and reason IDs, see Manage account statuses.

📘

Each reason ID is unique per organization and environment, and there is no endpoint to create one. In dormancy scenarios, the reason ID is associated with the DORMANT status. It is important to clearly specify which transactions are permitted when an account is in each status.

Dormancy inheritance

Dormancy configurations are established at either the division or program level. If an account is under a program that has a dormancy configuration, it adheres to the rules defined by that program's configuration. However, if an account also is under a division inside that program and the division has its own dormancy configuration, hierarchy rules apply.
For divisions, the hierarchy always follows this order: division → program. Since you cannot set dormancy configuration at the account level, accounts can only inherit it from either the division or program. If a dormancy configuration exists for both the division and program, the division’s configuration applies.

📘

In other scenarios on the Pismo platform, hierarchy always follows the order account → division → program. However, in dormancy configurations, it is not possible to define settings for accounts. It is important to take this rule into account when dealing with multiple divisions and programs. See the following example for further clarification.

Example: Division and program dormancy

In this example:

• Program A is bound to two divisions, 1 and 2.
• There are dormancy configurations for Program A and Division 2.
• Division 2 is below Division 1.
• Account A is within Division 1 and Account B is within Division 2.
• Account A inherits its dormancy configuration from Program A since there is no dormancy configuration in Division 1.
• Account B inherits its dormancy configuration from Division 2 even though Program A also has dormancy configuration.