The dormancy process reactivates an account whenever a transaction is posted, unless the transaction uses a processing code included in dormant_processing_codes. While this is appropriate for different types of operations, it does not account for variables that only exist outside of the Pismo platform—such as legacy transaction codes or custom identifiers—that should not influence a bank account’s dormancy state. To address this gap, the Pismo platform provides a dormancy reactivation exception feature that allows specific transactions to bypass reactivation based on attributes like metadata or soft descriptors. This capability is designed to support exceptions driven by variables external to the platform but intrinsic to your business rules, while preserving the platform’s standard behavior for all other cases.

Reactivation exceptions configuration

Use the reactivation_exceptions_config object in the Create or Update dormancy configuration endpoints to define attribute‑based rules that let specific transactions bypass dormancy reactivation. This object includes two fields.

How reactivation exception works

This is how you create and apply dormancy reactivation exception.

1. In the Create or Update dormancy configuration endpoint, set a value in the field property of the reactivation_exceptions_config object. This value can be either soft_descriptor—which tells the Pismo platform to check the soft_descriptor field in the credit or debit object, or at the root level—or metadata.

The request body follows this format.

{
   "reactivation_exceptions_config":{
      "field":"<attribute_field_name>",
      "values":[
         "<value1>",
         "<value2>",
         "..."
      ]
   }
}

2. Specify a value or values in the selected field (either soft_descriptor or metadata) in the credit or debit object or at the root level of the following endpoints.

• Post payment
• Post multi-leg payment
• Upload bulk file (include soft_descriptor and values fields with specified values in the bulk file)

💡

Notes

• You can configure up to 30 values in the values list.
• The metadata and soft_descriptor fields appear both within the credit and debit objects and at the root level of the Post payment request body. You can use either location to trigger dormancy exceptions defined in the dormancy configuration.
• When you set a value for soft_descriptor—whether in credit, debit, or at the root—or when you set a value in metadata, that value becomes the one used by reactivation_exceptions_config. For example, if reactivation_exceptions_config.field is set to soft_descriptor, the Pismo platform pulls the soft_descriptor value either from credit/ debit or the root.

Examples

Reactivation exception fails

Consider an example where values are specified in these fields.

Result: The value 005 in credit.soft_descriptor does not override the dormancy‑reactivation rule because the code configured in reactivation_exceptions_config.values is 001. Since the value provided in Post payment is 005—which does not match the configured exception—the Pismo platform does not treat it as an allowed exception, and the dormant account is reactivated.

Reactivation exception succeeds

Result: Since 001 is one of the custom values defined in reactivation_exceptions_config.values that blocks dormant accounts from being reactivated, it is applied, and the account remains inactive.