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.