The Promise To Pay Monitor

Fastpath: Please understand the concepts described in The Lifecycle Of A Promise To Pay and The Tendering Account May Differ From The Account Whose Debt Is Relieved before reading this section.

The Promise To Pay Monitor background process (referred to as PPM) is responsible for monitoring active payment plans. This process can cause a promise to pay (PTP) to become kept or broken (or being left as active).

Note: When is a promise to pay marked as broken / kept? It's important to understand that only the PPM can cause a promise to pay to become kept or broken. This means that if a customer makes a payment that satisfies a promise to pay, the promise to pay will only be marked as kept when the promise to pay monitor next runs. Analogously, if a payment is cancelled, nothing will happen to an active promise to pay until the PPM next runs. When the PPM next runs, it will see that the scheduled payment was not kept and it will break the promise to pay and schedule the ADM to be executed. When the ADM next executes, it will create a collection process (because the customer's debt will no longer be insulated by the promise to pay's scheduled payments).
Note: NSF Cancellations After A Promise To Pay Is Kept. If a payment is cancelled due to non-sufficient funds (NSF) after a promise to pay is marked as kept, the promise to pay will remain kept. But keep in mind that the promise to pay's account is scheduled for review by the ADM when a payment is cancelled due to NSF. When the ADM reviews the account's debt, it will no longer have an active promise to pay to insulate it and the account's debt will likely trigger a new collection process. Refer to How Promise To Pay Affect The ADM for more information.

The following points describe, at a high level, how the PPM monitors a promise to pay (PTP) for compliance.

  • The system selects all frozen, non-cancelled payment segments associated with the PP's account and debt class where:
    • The payment date is after the start date of the promise to pay, and
    • The payment's pay event has at least one tender that references the promise to pay's payor.
  • The system logically reduces / removes past and current scheduled payments (starting with the earliest scheduled payment) until the total amount of payment segments is exhausted (or there are no more historical / current scheduled payments).
Note: Paying promise to pay in advance. Scheduled payments with a future date are not logically removed / reduced. This means that if a customer makes advance payments on a promise to pay, it will not be marked as kept until all scheduled payment dates are in the past.
  • If all scheduled payments have been logically removed, the promise to pay is marked as kept.
  • If there exist scheduled payments where the pay date + grace days (grace days are defined on the promise to pay's payment method) is before the current date (i.e., a payment doesn't exist for a scheduled payment):
    • The promise to pay is marked as broken.
    • The PP's break algorithm (if any) is called (note, for European / Australian promise to pay, there are scenarios where the break algorithm can cause the promise to pay to become unbroken - when there aren't at least two missed, historical scheduled payments).
    • An ADM trigger is stored for the PP's account. This will cause the account to be reviewed by the ADM the next time it runs. And because the promise to pay is broken, its scheduled payments will no longer insulate the account's arrearage.
Note: Important! It's important that you schedule the PPM to run before the ADM so that it can break unpaid payment plans prior to the ADM subjecting the account's debt to collection criteria. Refer to How Promise To Pay Affect The ADM for more information.