Reminder and collection process (V2)

Enfuce standard credit product setup includes an automated reminder and collection flow that allows the issuer to effortlessly remind the customers of any overdue balance which decreases credit risk. Our comprehensive suite of reminder and collection events offers diverse rule options, empowering issuers to tailor a reminder and collection flow that best suits their needs and adheres to various regulatory standards across different markets.

The reminder and collection process is automated and all actions are triggered according to predefined rules set during the implementation project.

As described in a separate section, balances on a credit product are segregated and age as the billing cycle closes and due dates pass. The reminder process is triggered if a balance remains on the minimum-to-pay (“MTP”) accounts after the delinquency date has passed.

Reminder Events and Actions

Enfuce has implemented a series of reminder and collection events, from which the issuer can pick the ones needed to create a process flow designed for their needs. For every event, the issuer can choose what actions that event should perform. There are 7 reminder events and one collection event. Through our APIs and MyEnfuce platform, issuers can conveniently monitor the status of posted events, including delinquency status.

These events are seamlessly integrated into an event chain, enabling issuers to define threshold days between events. The Enfuce system diligently calculates and tracks the days, ensuring timely posting of subsequent events on the account. The events can also be set on fixed dates. The calculation for triggering the first event starts from the delinquency date. There can also be threshold values for the reminder events for example, overdue debt under 5£ will not trigger a reminder 2 event.

Reminder Process Overview

The issuer can choose which actions to add to the selected events.

Reminder ActionsAction Description
Soft block - Block card usageCard usage on the account level is blocked. In case of full incoming payment, the block is removed automatically.
Charge a reminder fee2 different reminder fees can be set.
Create a reminder fileThe issuer can send an official reminder letter to the cardholder.
Trigger a push notificationThe issuer can forward the information via SMS, e-mail, paper letter or through the app.

The collection event has a following default set of actions.

Reminder ActionsAction Description
Account status change: Account in collectionAccount status is changed.
Block interest postingInterest is not posted on the next billing cycle end.
Stop invoicingAccount is removed from the statement generation.
Hard block - Block card usageCard usage on the account level is blocked. Requires a manual block lifting.
Cards No RenewalCards will not be renewed whilst the account is in collection status

The card account and balance will remain in the Enfuce system on the overdue balance accounts even after the status has been updated to “Account In Collection”, and the issuer can continue to post payments to the account to reflect any potential payments the customer has made to the collection agency. Those can be finally written off from the accounts as well. See more information on the Balance write off section of the document.

Reminder fees

When sending reminders, the Enfuce system can also post reminder fees based on predefined values. Country-specific rules and regulations apply, but the system supports reminder 1 (transaction type REM1) and reminder 2 (transaction type REM2) fees for posting.

In case of any erroneous postings, these can be reversed using the Update Transaction API with the original document ID. Reversals are posted to the account as credits and are applied to debts according to payment priorities, such as starting with the oldest debts.

Example Use of the Events and Actions

Events can be triggered X days after either the billing cycle ends or the due date.

EventActions
Reminder 1Notify the cardholder on passed due date right after.
- Trigger a push notification
Reminder 2Notify the cardholder on upcoming reminder.
- Trigger a push notification
Reminder 3Hard/strong reminder.
- Create a reminder file
- Soft block card usage
- Charge a fee
Reminder 4Notify the cardholder on the second hard/strong reminder in case of no payment.
- Trigger a push notification
Reminder 5Second hard/strong reminder.
- Create a reminder file
- Charge a fee
Reminder 6Warning, collection notice will be sent in case of no payment.
- Trigger a push notification
Reminder 7Collection notice
- Create a reminder file
Send to CollectionSend to collection
- Account status change: Account in collection
- Block interest posting
- Stop invoicing
- Hard block - Block card usage
- Card no renewal

Reminder Statuses in the API

Account reminder statuses can be viewed from the Get Account API under “reminders” section of the call.

Reminder process related statuses visible through the account API:

Reminder eventValuesDefinition
"reminder1TriggerDate"YYYY-MM-DDDate when the reminder event has been/will be triggered
"reminder2TriggerDate"YYYY-MM-DDDate when the reminder event has been/will be triggered
"reminder3TriggerDate"YYYY-MM-DDDate when the reminder event has been/will be triggered
"reminder4TriggerDate"YYYY-MM-DDDate when the reminder event has been/will be triggered
"reminder5TriggerDate"YYYY-MM-DDDate when the reminder event has been/will be triggered
"reminder6TriggerDate"YYYY-MM-DDDate when the reminder event has been/will be triggered
"reminder7TriggerDate"YYYY-MM-DDDate when the reminder event has been/will be triggered
"collectionTriggerDate"YYYY-MM-DDDate when the collection event has been/will be triggered
"disableReminderProcess"True
False
"False" when it’s enabled
"True" when the reminder processes has been stopped. This is final status so the status cannot be set back to "False"
"reminderStatus""WAIT"
"REMINDER1_SENT"
"REMINDER2_SENT"
"REMINDER3_SENT"
"REMINDER4_SENT"
"REMINDER5_SENT"
"REMINDER6_SENT"
"REMINDER7_SENT"
"COLLECTION_SENT"
"STOPPED"
"DONE"
This status will be empty when there are now overdue invoices. Once invoice has been reached overdue on the delinquency date the status will be "WAIT".
After that it will state the most recently sent reminder or collection event.
If reminder process has been manually stopped it will show in "STOPPED" status. See further information in the exception handling section.
Reminder status will marked as "DONE" when payment is received to clear the process. Similarly it will marked as “done” if the next reminder event stays under threshold. Please see classifiers section for more information. After the last reminder event for the process has been triggered the final status will be always set as "DONE" on the following day.
"accountCardBlocks"
SOFT_BLOCK
HARD_BLOCK
"FALSE"
“TRUE"
"FALSE" status is shown when the cards can be used.
Once the "SOFT_BLOCK" is set to "TRUE" then the cards are blocked on the account level.
At the time of collection sending “hard block" is set to "TRUE"

Incoming Payments and Recovering from the Reminder Process

When a full payment is received, the account exits the reminder process. If the payment covers the past due balances, the reminder process is automatically discontinued. Subsequently, any soft blocks on the cards are promptly lifted, allowing the cardholders to resume spending without interruption.

However, if only a partial payment is made, the reminder process persists, and the account remains classified as delinquent until the outstanding overdue balance is settled in full.

In cases where the account has progressed to the collection phase, an incoming payment does not automatically remove it from the process, and the card remains blocked. To restore card functionality, manual intervention is required to lift the hard block through Account API/MyEnfuce portal.

Managing Exceptions and Special Circumstances

At times, deviations from the standard reminder and collection process are necessary to address exceptional circumstances effectively. Enfuce recognizes the importance of flexibility in managing such situations and has devised a range of tailored actions to assist issuers in navigating these deviations seamlessly.

Enfuce’s system empowers issuers to identify and manage exceptional cases by utilizing a series of predefined actions. These actions are specifically designed to address various scenarios that may arise, allowing issuers to handle each situation with precision and efficiency.

To initiate these exceptional actions, issuers can easily flag accounts by setting the classifier value ‘under investigation’ to ‘YES’. This classification serves as a clear indicator within the Enfuce system, signaling that the account requires special attention and prompting the activation of the appropriate actions to address the unique circumstances at hand.

By leveraging these tailored actions and classifiers, issuers can effectively manage deviations from the standard flow, ensuring that each situation is addressed promptly and appropriately.

Exception actions through API or MyEnfuce Portal

All the below listed exception action are reflected in the DWH files on the next day.

ActionHow
Under investigation"underInvestigation" to be set “true” through Update a credit account API Account under investigation will be ignored in the reminder process.
Set the minimum-to-pay percentage to 0"minimumToPay" "percentage" to 0 through Update a credit account API
Block interest posting"interestPostingEnabled" to “false” through Update a credit account API
Block / Unblock cardsCard blocks on the account level can be manually lifted by changing the "accountCardBlocks" values from “SOFT_BLOCK” or “HARD_BLOCK” into “false” at the Update Account API or vise versa, blocks can be manually set back on “true” from there.
Stop the reminder & collection process“disableReminderProcess" to “true” through Update a credit account reminder data API
Change the reminder dates"reminder1TriggerDate" in “YYYY-MM-DD format through Update a credit account reminder data API

Sample use cases

This chapter describes how the exception actions can be used in different use cases.

Deceased Customers and bankruptcy

In case of the death of the cardholder or a bankruptcy of an company, the issuer can set the expiry date on the customer level via Update Private Customer API. When the customer has deceased, the account will be frozen. This is done by setting a classifier “under investigation” value as “true” for the account. Accounts with this value will be excluded from the reminder process.

Additional Classifier values that can be changed via API:

  • set the minimum-to-pay percentage to 0
  • block interest posting

The changes are reflected on the next day’s DWH files, so the issuer can keep track of these customer cases.

In some countries, the issuer can sell the remaining debt to the collection agency. The issuer can manually change the account status to “Send to collection”.

The account balance from the death date can be found in the Account Balance DWH files.

Personal bankruptcy, payment plan

When the cardholder ends up in personal bankruptcy, the “under investigation” classifier can be used to stop the reminder process. This is done by setting a classifier “under investigation” value as “true” for the account.

On top of the classifier status update, these values can be changed via API:

  • set the minimum-to-pay percentage to 0
  • block interest posting

The cardholder has to follow a payment plan when the application is approved. Enfuce supports payment plans with the instalment feature, which can be configured separately.

Disputed invoice

When a cardholder encounters ambiguity or disagreement regarding their credit card invoice, they have the right to dispute it. Upon initiating a dispute, the invoice in question is flagged for investigation.

To facilitate this process, the Enfuce system features an ‘under investigation’ classifier. By assigning a “true” value to the ‘under investigation’ classifier for the respective account, the issuer can indicate that the invoice is currently under review, ensuring proper attention and handling.

In tandem with initiating the dispute, this allows for the temporary suspension of the reminder process associated with the disputed invoice. This prevents any unnecessary reminder notifications from being sent while the dispute is actively being addressed, offering customers a hassle-free experience during the investigation period.

Once the dispute is resolved, whether through clarification, adjustment, or resolution of the discrepancy, the “under investigation” classifier can be set off by changing it into “false”. If payment is made during the dispute resolution process, the reminder process automatically discontinues, ensuring that customers are not inundated with redundant reminders.

Customer needs more time to pay their invoice

When a customer contacts the customer support seeking an extension for payment of their credit card invoice, Enfuce’s flexible reminder process offers the ability to accommodate their request seamlessly. This adjustment can be easily facilitated via API integration or directly through the user-friendly interface of MyEnfuce.

By modifying the threshold waiting period, the initiation of the reminder process can be effectively postponed, ensuring that our customers have the necessary flexibility to manage their financial obligations. This feature becomes particularly advantageous when the next scheduled reminder event is not bound to a fixed date.

Moreover, for cases where fixed dates are employed within the reminder system, we offer the capability to temporarily halt the reminder process altogether. However, it’s essential to note that by opting for this option, the reminder process will not resume automatically in the event the customer fails to make the payment promptly.

Manual Sending to Collection

In some cases, the issuer might need to change the account status in the Enfuce system to “Send to Collection”. When the account status is changed, it will trigger the following actions in the Enfuce system:

  • Account status change: Account in collection
  • Block interest posting
  • Stop invoicing
  • Hard block - Block card usage

Balance Write-offs

Sometimes the debt collection fails for one reason or another, and the issuer needs to write off the debt either partially, or in full. The reasons could be customer bankruptcy or insolvency, fraud or even death of the customer.

Write-off of a card account debt is done through Transaction API. The issuer will define the write-off amount (either full balance or partial balance) and have a full audit trail of the balance types that have been written off (principal, fees, interest). The information can be found in the Account Balance DWH files.

Enfuce provides 4 different balance write-off transaction types (BWO1, BWO2, BWO3, BWO4), which the issuer can use to segregate the write-off reasons in their reporting. As the balances are written off, they are posted to specific Write-off GL accounts, which will allow the issuer to have the necessary data for bookkeeping. For regulatory reporting, more details can be added to the transaction’s text section, which will be then reflected in the DWH reports and can also be queried via transaction API. For example, in case only one transaction needs to be written off, the transaction ID can be inserted into the text section of the write-off.

In case of a positive balance write-off, the write-off is done through a support ticket to Enfuce. Our specialists will ensure that the write-off is done correctly.

Reminder & Collection in Data Warehouse files

The issuer can see the account delinquency level (DLQ_LEVEL) and reminder statuses from the Account Properties files and the monthly statement files. The reminder fees are presented in the Transaction file. All the reminder exception actions are presented in the Account files. On top the files all the reminder statuses can be seen in the Get Account API or in by checking the Account in MyEnfuce.

The DWH files are incremental, capturing any changes to accounts that were recorded the previous day. Account properties file includes ‘Reminder Sent’ events, allowing issuers to track the account’s dunning status. Additionally, if the reminder process does not proceed because the values fall below the threshold, a corresponding event will be triggered and reflected in the DWH file. None of the classifiers have any values by default, so if events haven’t been posted the values are empty.

Following classifier values will be updated in the statement and Account properties DWH files:

Classifier NameCodeValues Name/CodeDescriptionAPI/MyEnfuce
Reminder Process StatusREM_CL_STATUS- Reminder 1 / 1
- Reminder 2 / 2
- Reminder 3 / 3
- Reminder 4 / 4
- Reminder 5 / 5
- Reminder 6 / 6
- Reminder 7 / 7
- Collection / COLL
- None / N
- Stopped / S
Reminder 1 classifier will be triggered along the event to be visible on the next morning’s DWH file.
Reminder classifier will be set as ‘None’ when the past due balances are paid, even if the account would be in collection.
‘Stopped’ is final status that can be manually set.
Reminder trigger dates are visible in the Get Account API
It is possible to amend the threshold times and stop the reminder process in Update a Credit Account Reminder data API
Account Card Block
(Soft block)
INV_CARD_BLOCK- No / N
- Yes / Y
If set to ‘Yes’ then all cards for the account are blocked for the transactions. This will be automatically lifted when overdue balance has been paid.Card statuses are visible in the Get Account API
Cards can be manually blocked/unblocked in Update a Credit Account API
Card HardblockCARD_HARDBLOCK- No / N
- Yes / Y
If set to ‘Yes’ then all cards for the account are blocked for the transactions. This will not be automatically lifted by the systemCard statuses are visible in the Get Account API
Cards can be manually blocked/unblocked in Update a Credit Account API
CL. Under ThresholdCL_THRESH- None / N
- Yes / Y
In case the overdue balance is under the threshold for the next reminder event to be triggered the system will set the under threshold classifier into ‘Yes’ for the day and clears on the next day.N/A
Delinquency LevelDLQ_LEVELNo Debts / 0
Due / 1
Past Due 0-30 / 2
Past Due 31-60 / 3
Past Due 61-90 / 4
Past Due 91-120 / 5
Past Due 121-150 / 6
Past Due 151-180 / 7
Past Due 181-210 / 8
Past Due 211-240 / 9
Delinquency level is shadowing the aging of the balances in 30 days past due slots.N/A
Block Interest PostingBLOCK_INT_POSTINGNo / N
Yes / Y
Revolving or overdue Interests will not be posted in case the block interest posting has been set to ‘Yes’.Visible in the Get Account API
Possible to update in Update a credit account API
Under InvestigationUNDER_INVESTIGATIONNo / N
Yes / Y
When under investigation has been set to ‘Yes’ the reminder process for the account will be stopped for the time being.Visible in the Get Account API
Possible to update with Update a credit account API

Reminder File Content

The issuer can choose file creation as one of the actions to be attached to the reminder events. The file will be created when an event is posted to the Enfuce system, with this action attached to it. The file is delivered to the customer’s SFTP. The issuer can then use the file to create a reminder letter and send it to the cardholder.

Reminder XML file naming

  1. Enfuce_REMINDER_1_institution_yyyy-mm-dd_x_yyyymmdd.xml
  2. Enfuce_REMINDER_2_institution_yyyy-mm-dd_x_yyyymmdd.xml
  • Institution
    • Issuer number
  • yyyy-mm-dd
    • Reporting date to identify for which date the content was generated
  • X - running number to indicate the consisting file
    • File splitting is used to avoid big files with high volumes
    • The maximum amount of records: 99 per file
  • yyyymmdd_hhmmss
    • Timestamp of the file generation time in the Enfuce system

The file content

SectionField NameDetailsValues
filefileDateFile creation dateYYYY-MM-DD
filefileIdRunning number sequence (file split)1…
fileinstitutionIdIssuer number111111
fileinstitutionNameIssuer nameCompany Ltd
fileNumberOfRecordsNumber of records in the file1…99
filereceiverReceiver where the file will be sentIssuer
records / record→recordIdRecord sequence number in the file (max 99)0000001…
record / account→accountNumberCustomer account number
accountaccountNameCustomer name (Commercial or Private)Company ltd or John Smith
addInfotype - valueDate plan configuration codeFUNCTIONAL_DATES - FLTACCPRIV01
addInfotype - valueGL plan configuration codeGL_PLAN - FLTACCPRIV01
addInfotype - valueTariff plan configuration codeTARIFF_PLAN - CRDACCPRIV01
accountproductNameProduct nameProduct name configured in Enfuce payment platform - Prepaid, debit, credit, fleet etc.
accountproductCodeProduct codeCREDIT
accountstatusStatus of the account00
← / record / account
record / balances →amount, typeBalance type with amountTOTAL_BALANCE
balancesamount, typeBalance type with amountTOTAL_DUE
DUE
PAST_DUE
OVD_01
OVD_02
TOTAL_BALANCE
OPENING_BALANCE
INVOICE_AMOUNT
INVOICE_DUE_AMOUNT
← / record / balances
recordbillingDateBilling dateYYYY-MM-DD
recordbillingPeriodEndDateBilling period end dateYYYY-MM-DD
recordbillingPeriodStartDateBilling period start dateYYYY-MM-DD
record / client →addInfos / AddInfotype / value
clientclientNumberIssuer number
clientcompanyNameIssuer nameCompany Ltd
clientemailIssuer email addresscompany@mail.fi
clientlocaleClient country locationfi_FI
en_GB
sv_SE
no_NO
is_IS
← record / client
recordcreditLimitAccount credit limit0.0
← record / deliveryAddressaddressLine1Street addressStreet 1
deliveryAddresscityCityHelsinki
deliveryAddresscountryCodeISO alpha-3 codeFIN
deliveryAddresscountryNameCountry name in lettersFinland
deliveryAddresszipCodePostal code00100
deliveryAddressaddressLine2Street address / P.O. boxBox 100
← record / deliveryAddress
recorddueDateInvoice due dateYYYY-MM-DD
interestRates / interestRate →codeInterest rate codeINT_OVD
interestRateeffectiveDateStart dateYYYY-MM-DD
interestRatenameInterest nameInterest Rate - Overdue MTP
interestRatevalueInterest rate percentage00.00
← interestRates / interestRate
fees / fee ->codeREM1_FEE
REM2_FEE
effectiveDatePosting dateYYYY-MM-DD
nameFee nameReminder 1 Fee
Reminder 2 Fee
feeBaseSet fee value0.0
← fees / fee
recordminimumToPayPercentageMinimum percent to be paid100
recordpaymentTermPayment termsPAY_TERM - 1…31
recordrecordIdRecord sequence number in the file0000001
recordreferenceNumberPayment reference number001234567890011
← records / record
← file

Reminder and collection process (V1)

The standard credit product setup includes an automated reminder and collection flow that allows you to effortlessly remind your customers of any overdue balance. This decreases credit risk and is required in many markets to be compliant with legislation and regulation. The default process is that an end-customer is reminded twice of the overdue debt before sending the debt to collection.

The reminder and collection processes are automated and all actions are triggered according to predefined rules that are set during the implementation project. The rules you get to define are:

  • How many days after the due date should the first reminder be sent?
    • What is the fee for the first reminder?
  • How many days after the due date should the second reminder be sent?
    • What is the fee for the second reminder?

As described in a separate section, balances on a credit product are segregated and age as the billing cycle closes and due dates are passed. If there remains a balance in the minimum-to-pay (MTP) accounts the day after the due date has passed, the reminder process is triggered.

First reminder for an overdue invoice

Enfuce will start calculating the reminder days when there is an unpaid due balance after the delinquency date. The delinquency date is set per issuer definitions during the implementation project as days after the due date. The calculation start date is indicated in the daily data export files by the account property ‘CL_REM1_ST’ which is updated to ‘W’ (Waiting) after the due date. The account is constantly monitored and the calculation stops in case the customer makes a payment that covers the entire overdue balance. If a payment is received before the reminder is sent, the ‘CL_REM1_ST’ property is updated from ‘W’ (Waiting) to ‘N’ (No) during the End of Day processes.

If the customer does not pay the overdue balance by the time the predefined amount of days since the delinquency date has passed, the account property is updated from ‘W’ (Waiting) to ‘S’ (Sent). Simultaneously the potential fee for the first reminder is posted on the card account. Sending reminder 1 is also the default threshold for when the account will be considered blocked, i.e., all authorisations will be declined due to delinquency. While the authorisations are declined, the status of the account or cards will not change. When the full payment is received, the account and cards will be unblocked immediately when the payment is posted to the card account.

Second reminder for an overdue invoice

As soon as the account property ‘CL_REM1_ST’ property is updated to ‘S’ (Sent), Enfuce will start calculating the days for the second reminder. This calculation start is reflected in the account property ‘CL_REM2_ST’ which is updated to ‘W’ (Waiting). The same monitoring of the account applies for the second reminder and the calculation stops in case the customer makes a payment that covers the entire overdue balance. If a payment is received before the reminder is sent, the ‘CL_REM2_ST’ property is updated from ‘W’ (Waiting) to ‘N’ (No).

If the customer does not pay the overdue balance by the time the predefined amount of days since the first reminder was sent, the ‘CL_REM2_ST’ account property is updated from ‘W’ (Waiting) to ‘S’ (Sent). Simultaneously the potential fee for the second reminder is posted on the card account. As the second reminder is actualised (i.e. ‘Sent’), the calculation for sending to collection starts.

Collection process for revolving credit

As soon as the account property ‘CL_REM2_ST’ property is updated to ‘S’ (Sent), Enfuce will start calculating the days for sending to collection. This calculation start is reflected in the account property ‘CL_COLL_ST’ which is updated to ‘W’ (Waiting). The same monitoring of the account applies for sending to collection and the calculation stops in case the customer makes a payment that covers the entire overdue balance. If a payment is received before sending to collection, the ‘CL_COLL_ST’ property is updated from ‘W’ (Waiting) to ‘N’ (No).

If the customer does not pay the overdue balance by the time the predefined amount of days since the second reminder was sent, the ‘CL_COLL_ST’ account property is updated from ‘W’ (Waiting) to ‘S’ (Sent).

Sending to the collection will trigger the following actions at Enfuce:

  • Interest accrual will be discontinued
  • Card account will be excluded from statement generation (as debt collection is expected to be continued by the collection agency)
  • Account status is updated to ‘Account In Collection’

Based on the updated ‘CL_COLL_ST’ account property in the daily data export files, you can take action and initiate the collection process with your chosen debt collector. The card account and balance will remain in the Enfuce system even after the status has been updated to ‘Account In Collection’, and the issuer can continue to post payments to the account to reflect any potential payments the customer has done to the collection agency.

Balance Write-offs

Sometimes the debt collection fails for one reason or another, and the issuer needs to write off the debt either partially, or in full. The reasons could be customer bankruptcy or insolvency, fraud or even death of the customer.

Write-off of a card account debt is done through Transaction API. The issuer will define the write-off amount (either full balance or partial balance) and have a full audit trail of the balance types that have been written off (principal, fees, interest). The information can be found in the Account Balance DWH files.

In case of a positive balance write-off, the write-off is done through a support ticket to Enfuce. Enfuce specialists will ensure that the write-off is done correctly.

Enfuce provides 4 different balance write-off transaction types (BWO1, BWO2, BWO3, BWO4), which the issuer can use to segregate the write-off reasons in their reporting. As the balances are written off, they are posted to specific Write-off GL accounts, which will allow the issuer to have the necessary data for bookkeeping. For regulatory reporting, more details can be added to the transaction’s text section, which will be then reflected in the DWH reports and can also be queried via transaction API. For example, in case only one transaction needs to be written off, the transaction ID can be inserted into the text section of the write-off.