Managing account statuses within the Pismo platform involves configuring and mapping account status change reasons to your organization. Key statuses include INACTIVE, DORMANT, and UNCLAIMED, which require specific change reasons to function correctly. Dormancy types are defined based on the period of inactivity and are set at the division level.

Account status changes impact operational permissions, such as allowing or restricting debit and credit postings, as well as forced credits and debits. To ensure accurate processing, it's crucial to validate and configure mappings during the organization's setup. This includes setting up fee configurations and deductions. Proper management of account statuses helps maintain efficient and accurate tracking of account activities within the system.

Account statuses common to all accounts

The status field for any account can contain one of the following values:

You can use the Update status endpoint to change the account status to one of the values described previously. See Account status for more information.

Manage inactive/dormant transaction banking accounts

Transaction banking accounts come with extra statuses to help you manage inactive or dormant accounts. An account becomes inactive or dormant when no transactions occur for a specific period.

The Pismo platform allows you to define three types of dormancy based on how long the account has been inactive. These dormancy types are set at the division level, which is explained in the following sections.

Account statuses specific to transaction banking accounts

The additional account statuses for transaction banking are as follows:

• INACTIVE
• DORMANT
• UNCLAIMED

For transaction banking accounts in any inactive status, a customer-initiated transaction reactivates the account and restores its status to NORMAL. Account status reasons help control the types of transactions accepted into the account, thereby activating it.

An automated process within the Pismo platform checks for accounts that have been idle for a specified length of time. When such an account is found, its status is changed to one of the predefined values. Typically, an idle account first becomes INACTIVE. If it remains INACTIVE for a prolonged period, it changes to DORMANT. If it stays DORMANT even longer, its status changes to UNCLAIMED. The duration an account must remain idle before each status change depends on your custom settings. You can configure the inactivity period, the resulting status, and the reason for the status change after the specified length of time.

Configure dormancy statuses and change reasons

The available account status change reasons for this feature are as follows:

These parameters must be applied by division using the Create dormancy configuration endpoint. Instead of providing the reason, you must pass an external_reason_id. To obtain a list of these IDs, use List account status reasons. The following code snippet demonstrates the type of response you should receive when you call List account status reasons.

{
    "code": "ALL",
    "reason_id": 1619,
    "show_user": false,
    "description": "Any",
    "account_status_id": 2421
},
{
    "code": "ALL_NO_FORCE_ALLOWED",
    "reason_id": 1440,
    "show_user": false,
    "description": "Any - No Force Allowed",
    "account_status_id": 2421
},
{
    "code": "CREDIT_ONLY",
    "reason_id": 1618,
    "show_user": false,
    "description": "Credit Only",
    "account_status_id": 2421
},
{
    "code": "CREDIT_ONLY_NO_FORCE_DEBIT_ALLOWED",
    "reason_id": 1438,
    "show_user": false,
    "description": "Credit Only - No Force Debit Allowed",
    "account_status_id": 2421
},
{
    "code": "DEBIT_ONLY",
    "reason_id": 1421,
    "show_user": false,
    "description": "Debit Only",
    "account_status_id": 1316
},
{
    "code": "DEBIT_ONLY_NO_FORCE_CREDIT_ALLOWED",
    "reason_id": 1439,
    "show_user": false,
    "description": "Debit Only - No Force Credit Allowed",
    "account_status_id": 2421
},
{
    "code": "FORCE_CREDIT_ONLY",
    "reason_id": 2774,
    "show_user": false,
    "description": "Force Credit Only - No Force Debit Allowed",
    "account_status_id": 1316
},
{
    "code": "FORCE_DEBIT_ONLY",
    "reason_id": 2775,
    "show_user": false,
    "description": "Force Debit Only - No Force Credit Allowed",
    "account_status_id": 1316
},
{
    "code": "NONE",
    "reason_id": 1620,
    "show_user": false,
    "description": "Manual",
    "account_status_id": 2421
},
{
    "code": "NONE_NO_FORCE_ALLOWED",
    "reason_id": 1441,
    "show_user": false,
    "description": "Manual - No Force Allowed",
    "account_status_id": 2421
}

The response is an array of status objects, where each object consists of the code for the new status, the external_reason_id, and the description.

💡

Notes

• If a transaction is posted and the account status is either INACTIVE, DORMANT, or UNCLAIMED, the account's status reverts to NORMAL unless the processing code for the account is listed in dormant_processing_code in Create dormancy configuration.
• When you use the Update dormancy configuration endpoint, an account enters the dormant state (INACTIVE, DORMANT, or UNCLAIMED) only after the specified number of days has elapsed without any transactions.

The following code demonstrates how you pass the values for these parameters in the body of the Update dormancy configuration request:

{
    "check_time": "09:00:00",
    "target_type": "DIVISION",
    "target_id": "{{division.city.code}}",
    "statuses": [
        {
            "status": "DORMANT",
            "reason_external_id": "CREDIT_ONLY",
            "days": 1,
            "reactivation_with_last_restriction": true,
            "restrictions": [
                {
                    "current_reason_external_id": "DEBIT_ONLY",
                    "new_reason_external_id": "CREDIT_ONLY"
                }
            ]
        }
    ],
    "dormant_processing_codes": [
        "220040"
    ],
    "deny_forced_transaction_reactivation": true
}

The following table outlines the relationship between various account status change reasons and the corresponding permissions for operations on those accounts. It specifies whether debit and credit postings are allowed, as well as whether forced credits and debits are permitted under each account status type. This detailed breakdown helps in understanding the operational capabilities associated with different account statuses.

💡

Account status change reasons must be mapped to the organization (Org) during its setup. For the INACTIVE, DORMANT, and UNCLAIMED statuses to function correctly, they must be assigned specific account status change reasons. Note that there is no standard behavior predefined for these statuses at the Org level.

Here is the standard account status behavior, note that the account status reasons always override the standard behavior of account status.

Update account status and reasons

To update the account status or reason, please note the following:

• Final Status Restrictions: Changes cannot be made if the account is currently in a final status, such as UNCLAIMED or CANCELED. To modify an account in a final status, you must use the Roll back transaction banking account status endpoint.
• Change to Final Status: It is not possible to change an account status to a final status or to one that is specified in the dormancy configuration the account adheres to. If you intend to transition an account to a final status, use the Close transaction banking account endpoint.

Rollback account

To rollback an account, it is important to consider a few key points. First, the account's current status must be a final status. Second, while you are allowed to choose a new status and reason for the account during the rollback, this new status cannot be a final status or a dormant status.

Close account

To close an account, several validation criteria must be met. The account must not have any scheduled payments, and there should be no balances in the account, whether earmarked or book balance.