A repayment agreement is an agreement between the bank and a customer whose account is overdrawn, with the aim of settling the overdue amount.

According that agreement, the customer transfers or deposits a fixed amount, e.g. monthly, to their account, or this amount is collected by the bank (from an external account, if necessary). At the same time, the compliance with the repayment agreement is monitored and checks are carried out to determine whether it can be terminated early because the overdraft has been settled.

Creating a Repayment Agreement

A repayment agreement can be created at any point in the dunning workflow, as soon as arrears exist.

A declaration of consent by the customer with a repayment agreement in practice results in a change in contract. This implies that the contract can be terminated at any time if the terms of the repayment agreement are not complied with. Hence, in such cases, it is neither legally necessary to send any further reminders (1st / 2nd / 3rd reminder) nor to respect certain deadlines, before proceeding with an (extraordinary) termination. This means that after creating a repayment agreement, the account no longer follows the standard dunning workflow.

Instead, in the context of a repayment agreement, there are following three dunning levels:

  • Ongoing Repayment Agreement
  • Breach of a Repayment Agreement
  • Extraordinary Termination

The “key prerequisite” for creating a repayment agreement is that an overdraft exists on the respective account. As soon as a repayment agreement has been added, the account is assigned the “Ongoing Repayment Agreement” dunning level.

The default dunning workflow focuses on the overdraft amount and duration of the overdraft. However, this changes after adding a repayment agreement. After that, only the compliance with the terms of the repayment agreement is monitored. The overdraft days counter continues to run in the background independently of a repayment agreement.

There are only two ways to exit this “reduced” dunning workflow (with the three levels mentioned above): Either enough funds are transferred or deposited in the account again and it returns back to the “Without arrears” dunning level, i.e., to the standard dunning workflow, or the account is terminated, changes to the “Extraordinary termination” dunning level and is ultimately closed.

Ongoing Repayment Agreement

Since, on one hand, the outstanding balance of the account may increase or decrease at any time due to incoming or outgoing payments and, on the other hand, the amount of the credit limit held for the account, which is linked to the lending value of the securities depository, may fluctuate at any time, a repayment agreement does not have a real maturity date. It will remain in effect until the account has sufficient funds again. Only then the repayment agreement will be terminated automatically.

Therefore, the maturity of a repayment agreement is recalculated on daily basis. The end date of a repayment agreement is needed inter alia for the Impairment-Calculation (in step 2, the ECL is calculated up to the end of maturity of the RZV).

As soon as a repayment agreement has been added, two factors are checked separately on a daily basis. These checks are carried out independently of the overdraft days of the regular dunning workflow:

  1. Does the customer pay his instalments on time?
  2. Has the lending value / deposit amount (i.e., the collateral value) fallen below the threshold, defined in the repayment agreement?

The checks are positive if (1) the customer always pays the instalments on time and (2) the current lending value / deposit amount does not fall below the threshold value agreed in the repayment agreement during that time.

An error on any of these checks immediately requires the responsible officer to react (see below).

Verification of regular payments

A check is made on each posting day to determine whether the account is still overdrawn. This check is carried out on basis of the payment plan, which is calculated in accordance with the business rules (= instalments, suspensions, deferrals).

Whenever a payment date is reached, the respective instalment is considered as due and a corresponding payment is expected. Appropriate payments are then assigned to the respective instalment:

  • As soon as an instalment is due, suitable payments will be automatically
  • For each new received payment, an open instalment is automatically
  • There is also the option to perform or change the payment assignment manually via the user interface.

The following rules and special features apply:

  • Waiting Period

There is a waiting period of two working days, which may lie between the date of the instalment and the value-date of the payment, without the verification of regular payments being considered negative.

  • Filtering by text key/incident code

An incoming payment is only considered in the automatic allocation if it has a specific text key/occurrence code, e. g.  

    • 11620 - SEPA bank transfer incoming
    • 11611 - Order sale

The permissible text keys/occurrence codes can be changed via parametrization. This restriction does not apply to manual payment allocation.

  • Filter by maximum value-date in the past (taking early payers into account)

A payment may be made not more than ten days (value-date) before the payment date of the respective instalment of the repayment agreement, otherwise it will not be taken into account in the automatic allocation.

The Number of days can be changed via parametrization. This restriction does not apply to manual payment allocation.

  • Filter payments with to large amounts (unscheduled repayment)

A payment will only be considered in the automatic allocation if its amount is less than 200% of the amount of the respective instalment of the repayment agreement, otherwise it will be considered as unscheduled repayment and will be ignored for the repayment of the instalment.

The percentage (based on the amount of the instalment of the repayment agreement) can be changed via parametrization. This restriction does not apply to manual payment allocation via user interface.

  • one payment = one repayment

In case of automatic allocation, a payment is generally used as repayment for one instalment (even if the balance of a payment would be sufficient for another instalment).

This restriction does not apply to manual payment allocation via user interface.

An instalment will only be considered as fully paid, if the sum of the allocated instalments of incoming payments fully covers the instalment amount. If at least one instalment is not fully paid, the check for regular payments shall be considered negative.


Verification of compliance with thresholds

When a repayment agreement is set up, a threshold amount can be agreed, which is checked on daily basis regarding the lending value / deposit amount of the associated portfolio. The threshold amount is then an integral part of the repayment agreement, even if customers cannot influence the development of the lending value of their accounts. This check is carried out on each booking day to calculate whether the value has fallen below the threshold and, if so, by how much. There are three options for this check:

  • The defined threshold refers to the current deposit amount (market value) of the account. In this case, the market value of the entire account must not fall below the threshold.
  • The defined threshold refers to the current lending value of the account. In this case, the lending value of the entire account must not fall below the threshold.
  • No threshold has been defined (for example, because there were no values available for the account). In this case, this second check will be omitted.

Is the value below a defined threshold value, the verification with the thresholds shall be considered negative.

Consequences in case of negative verification results

It is possible that none, one or both verifications end negative at the same time. For accounts with a repayment agreement, the result of the two checks is displayed accordingly.

In case one of the two checks is negative, the dunning level of the account automatically changes from “Ongoing repayment agreement” to “Breach of repayment agreement”.

Apart from that, a follow-up is generated which notifies the responsible officers about the non-fulfilment of the repayment agreement. Their manual action is then required. The follow-up remains active until the account quits the “Breach of repayment agreement” dunning level, either in a positive way, i.e. after a new agreement set up with the customer, or in a negative way, i.e. after an extraordinary termination.


Breach of a Repayment Agreement

In case of a breach of a repayment agreement, the responsible officers either need to take action on the corresponding follow-up or open the corresponding account with the “Breach of repayment agreement” dunning level in the “Current Accounts” tile in the “Lifecycle management” swimlane. The ongoing repayment agreement, which has been breached in this case, can be viewed in the account data.

Usually, the responsible officers should contact the account holder to resolve the breach in contract using one of the following options:

  • Granting a payment term extension:

A Payment Term Extension can be granted both in the case of open instalments and in case that there is no delay (yet) in payment.

On one hand, a payment term extension can be granted in form of a suspension, in which case the outstanding instalments up to and including the specified date are no longer due and no longer need to be paid by the customer at that time. In this case, instalments continue with the next regular instalment after the specified date. This in turn extends the payment plan of the repayment agreement. For example, if two instalments are suspended, the payment plan will be extended by these two instalments.

On the other hand, a payment term extension can be granted in form of a deferral, which means that an outstanding instalment is not cancelled and appended to the payment plan, but the payment date is postponed by just a few days. Usually, this only involves a short period of time before the payment date of the next regular instalment. In case of a deferral, the payment frequency of the repayment agreement is maintained, while just the payment date of a single instalment is slightly delayed.

However, a deferral can be granted multiple times in a row. So, if the instalment still has not been paid after the deferral period has expired, a further deferral may be granted.

Once an extension has been granted, the instalment is no longer considered overdue, which means that the repayment agreement is no longer considered breached. For any extension granted, the resulting change will be reflected in the payment plan.

  • Change a payment term extension

If an extension of the repayment agreement has been granted and the extension has not yet been completed, the responsible case officers also have the option to change the Payment Term Extension.

A change to an existing Payment Term Extension means extending or shortening it. In extreme cases, the extension of the deadline may be shortened to the current booking day, which then effectively corresponds to the termination of the deferral/suspension. A shortening to the past which would correspond to a retroactive change is not possible.

If the Payment Term Extension to be amended is already running, only the end date of the Payment Term Extension can be changed. If the Payment Term Extension to be amended is not yet running, both the start and the end date of the Payment Term Extension can be adjusted.

If the Payment Term Extension to be amended is not yet running, it can also be completely deleted.

The type of Payment Term Extension cannot be changed, i.e. it is not possible to change a deferral into a suspension or vice versa.

  • Manual payment allocations

In addition to the automatic payment assignment, the responsible officer, can also manually execute or change the assignment of payments to instalments.

Unlike automatic allocation, a payment can also be split by manual allocation to use it for two or more instalments.

  • Accept Instalments manually

The responsible officer has got the opportunity to manually set due, not (fully) paid instalments to “OK” so that the unpaid balance is accepted and the instalment is considered as fully paid by the system.

This process can also be reversed, if necessary, by a responsible officer.

If the granting or modification of a Payment Term Extension, the carrying out of manual payment allocations or the manual acceptance of instalments, lead to no outstanding instalments being available, the following shall apply:

    • The account automatically switches to the reminder level "Ongoing Repayment Agreement" and leaves the status "breach".
    • The follow-up regarding the change to the “Breach of repayment agreement” dunning level is automatically closed at the same time.
  • Partial/total liquidation of deposit amounts

The liquidation amount will be credited to the corresponding account. If this credit is sufficient to cover the current overdraft amount, the account will no longer be overdrawn after the next end-of-day processing.

Result:

    • The account is automatically assigned a dunning level without arrears and is thus again subject to the normal dunning workflow.
    • The follow-up regarding the change to the “Breach of repayment agreement” dunning level is automatically closed at the same time.
    • The ongoing repayment agreement is automatically terminated.
    • At the same time, a new “Repayment agreement terminated/fulfilled” follow-up is created.

Since this follow-up does not require any real action in the system, it only has to be closed manually after reviewing it.Extraordinary Termination

  • Responsible officers also have the option to terminate a contract, perhaps in conjunction with a partial or complete liquidation of the deposit items. For this purpose, the account must be manually assigned to the “Extraordinary Termination” dunning level.

Result:

    • The account switches to the “Extraordinary Termination” dunning level. In this context, no document is created automatically, i.e. the termination letter to the customer must be written manually.
    • The follow-up regarding the change to the “Breach of repayment agreement” dunning level is automatically closed at the same time.

After that, the usual steps for closing the account are performed in the customer data system: (Total/partial) liquidation, write-off, preparation of account statement, charge-off. After this is done, the account will be delivered as “closed” with a balance of “0”.

Result:

    • The ongoing repayment agreement is automatically terminated.
    • Unlike terminations for other reasons, in this case, no “Repayment agreement terminated/fulfilled” follow-up is created.
  • Changing the repayment agreement

The responsible officers also have the option of changing the existing terms (instalment amount, threshold) of an ongoing repayment agreement.

In case of a change in the repayment agreement, it remains in principle; only the rules below the repayment agreement are changed from the due date. Unpaid or only partially paid instalments according to the previous repayment agreement rules remain open and wait for payment to be received.


In addition to these manual actions on the part of the responsible officers that might have been taken due to a “Breach of repayment agreement” follow-up, there is also a possibility for the breach to be resolved automatically, for example:

  • in case of an outstanding instalment, when the payment is eventually received before a responsible officer has contacted the customer.
  • in case the defined threshold is exceeded, when the market or lending value rises again so that the threshold defined for the repayment agreement is no longer below.

In such cases, the “not breached” dunning level is automatically reassigned:

  • The account automatically changes back to the “Ongoing repayment agreement” dunning level.
  • The follow-up regarding the change to the “Breach of repayment agreement” dunning level is automatically closed at the same time.

After that, the repayment agreement continues and is monitored as usual.

Termination of a repayment agreement

If the account is no longer overdrawn

  • because, a higher amount has been transferred or deposited to the account or
  • because the regular end date of the repayment agreement has been reached and the sum of all individual instalments has settled the overdraft, or
  • because the lending value has increased, which simultaneously results in a higher account limit, it also turns the account to not being below the overdraft threshold,

then

  • the repayment agreement will be automatically (prematurely) terminated, and
  • the account changes back to a dunning level in the regular dunning workflow without arreas, and then
  • a new “Repayment agreement terminated/fulfilled” follow-up is created to notify the responsible officers (except for when the account is closed):

This follow-up is particularly important for repayment agreements with self-payers, as the responsible officers must inform the respective customer about discontinuing the instalment payments. Since this follow-up does not require any real action in the system and is purely informational, it only has to be closed manually after completion (e.g. after a phone call).

If one of the instalments (e.g. the most recent one) is higher than the outstanding overdraft, the instalment amount will not be reduced. The instalment amount specified in the repayment agreement will always remain the same. This is particularly important for automatic direct debits.

Repayment agreements for cancelled accounts

Creating a new repayment agreement or modifying an existing repayment agreement is also possible after a regular or extraordinary termination.

After a termination/fulfilment of a repayment agreement whose corresponding account was previously terminated, the account always returns to the termination level at which the repayment agreement was originally created. At the same time, the dunning workflow is set to “manual”, i.e. the account is no longer subject to the automatic workflow.

Regardless of how often a repayment agreement is created or modified after a prior account termination, no dunning letters will be issued again upon returning to the original dunning level. Only after a termination has been completely revoked (i.e. the regular dunning workflow has been reset to a dunning level without arrears), the dunning workflow has been started over, and then the account is terminated again, dunning/termination letters can be issued again.

Even in the event of an account closure, the account is reset to the dunning level it was assigned prior to the repayment agreement. If there was no termination prior to the repayment agreement, the account will be reset to a dunning level without arrears instead.

From a termination dunning level (regular or extraordinary termination), an account can be reset to a dunning level without arrears. Then, the automatic dunning level monitoring is re-enabled for the account.

Even in case of an ongoing or breached repayment agreement, an extraordinary termination can be initiated, which in this situation is the only way to change the dunning level manually. However, since it is also possible to create a repayment agreement after a termination (see above), this option is only available as long as no termination has been initiated before the repayment agreement was created.

  • No labels