AI Adoption GuideBankingReview
Early arrears prediction
ML scores accounts 60 to 90 days before first missed payment using transaction behavioral signals, enabling proactive collections outreach.
Banking processAcquireOnboardOpenFundTransactServiceReviewClose
By Don, DoneThat’s AI coach · updated
A score is a ranked list with cites, not arrears
Early arrears prediction should leave collections with a ranked outreach list, each row carrying the transaction cites that drove the score. It should not mark the account as late, change contractual status, or fire an automated default, promise-to-pay, or hardship letter.
A score is a hypothesis that this account is more likely than its peers to miss an upcoming payment. The first missed payment is still the event that creates arrears. Until that date, the customer is current. Treating the score as arrears is the fastest way to mis-contact, mis-report, and send current accounts down a path that belongs only after a contractual miss.
The prediction horizon is a design choice, not a result you have already proven. Teams usually look one to three statement cycles ahead so there is time for a repayment conversation before a due date is missed. Whether that window is sixty days, ninety days, or a single cycle is an operating decision you document and back-test. Do not publish the window as a performance claim.
What collections needs on the row is the why: which inflow changed, which spend categories contracted, over how many cycles, and relative to that customer's own baseline. A rank without cites is a black box. A cite without a rank is a research note. The work product is both.
First-party spend and inflow as the scoring inputs
Score from data you already hold on the account. Useful signals are changes in the customer's own pattern, not a one-day snapshot and not a bureau score used as a stand-in for behaviour you can see.
Inflow change is the first place to look. Salary, benefit, or other regular credit that arrives later, smaller, or not at all, against that customer's history, is a reason the next due date may be missed. Pair it with spend change: grocery, fuel, utilities, and other essential categories that contract, or discretionary spend that drops while essential spend holds. Either pattern can be real. Neither is arrears.
Build the score on first-party deposits and card or current-account spend. Bureau files from providers such as Experian or Equifax can sit beside the score as context for later treatment. They should not be the reason an account enters the early-outreach list. If the only signal you have is a bureau movement, you are doing continuous credit risk reassessment, which is a different job.
Illustration, not a measured case. A current-account customer usually receives payroll on the last Thursday of the month and spends in a stable band on groceries and fuel. This month payroll posts the following Tuesday, later than the customer's own median, and grocery plus fuel spend over recent weeks sits well below that customer's baseline. The model ranks the account high and cites delayed payroll, essential-spend contraction versus own baseline, and a still-current instalment. Collections sees someone who may have changed payday or lost hours, not someone who has missed. The next action is a conversation owned by collections, not a status change.
Calibrate against the customer's own history before you calibrate against the book. A teacher paid monthly looks different from a contractor paid irregularly. A payday shift the customer has made before is a known pattern. Calling that customer with a collections script is a failure that looks like diligence.
How the queue is built and who may contact
The model scores. Operations queues. Collections contacts. Do not collapse those three steps.
Scoring produces a rank and the cites. Queuing applies policy: product, days to due, prior treatment, vulnerability flags, deceased or gone-away markers, complaints, and do-not-contact codes. Only then does a person in collections pick the next row. The contact is an offer to talk about the upcoming payment, a reminder of channels, or a signpost to a hardship process. It is not a default.
Do not auto-default from the score. Do not auto-issue a collections letter. Do not auto-restrict the card. Those actions belong to arrears policy after a contractual miss, or to a separate credit-decision process with its own evidence and appeal path. Early prediction exists so a person can choose to reach out while the account is still current.
CRM and workflow tools in the Salesforce class, and core banking platforms in the Temenos class, are where the queue usually lives. Use them as the workbench: assign an owner, record the outcome, keep the cites attached to the account. Do not treat "the model wrote to the CRM" as "collections has spoken to the customer."
Give each row a hold-out reason, not only a rank. If vulnerability screening has not run, the row does not leave the queue for a collections script. Route it to vulnerable customer detection first. If the cites look like the customer is leaving the bank rather than struggling to pay, hand off to pre-closure churn interception instead of a collections call. Those are different conversations. Mixing them trains staff to use the wrong tone on the wrong evidence.
Payday shifts, vulnerability flags, and other false starts
Three failure modes show up in almost every early-arrears programme. Put them in the queue rules, not in a review after complaints arrive.
Calling a customer who just changed payday. Delayed inflow is a scoring input. It is also how monthly-paid customers look when payday moves for a bank holiday, a new employer, or a pay-date change they already reported. Before outbound contact, check whether payroll or the regular credit has a scheduled or recently confirmed new date. If it does, drop or defer the row. A high score plus a known payday change is not an outreach priority. It is a model miss you should feed back into the baseline.
Treating the score as arrears. Once operations start talking about predicted late accounts as if they were already late, status, reporting, and scripts drift. Keep language precise in the queue: elevated likelihood of a future miss, currently up to date, cites attached. Training, QA, and complaint handling should treat a collections script on a current account as a quality fail unless the contact was pre-due support and the customer was screened.
Skipping vulnerability checks. An early-outreach list is a list of people who may already be in financial difficulty. That is exactly when a standard collections script is the wrong first contact. If the account has a vulnerability flag, a recent bereavement or illness note, a mental-health marker, or incomplete screening, do not dial from the early-arrears queue. Finish vulnerability screening, then decide whether the right owner is a specialist support team, not collections. Contacting a vulnerable customer with a collections script is not a model error. It is an operating error you can prevent in the queue.
Transaction cites are not an annual review pack. If a relationship manager needs a documented narrative, use annual review document generation rather than pasting model output into the file.
Bureau files, CRM, and the core as supporting systems
Experian and Equifax already sit in most banks as bureau and scorecard suppliers. Salesforce-class CRM and Temenos-class cores already hold assignment, balances, and due dates. Use them so the collector sees one row with cites attached. Do not let any of them auto-action an account because a rank crossed a threshold.
A rising chance of a missed payment is not a reason to re-price or restrict without a credit decision, and it is not continuous credit risk reassessment. Early arrears work is quality of outreach: current customers, in rank order, with cites, after vulnerability and payday checks, contacted by collections only when contact is the right treatment.
The production test is simple. Can a collections lead open the queue, read why each name is there, see who must not be called, and take an action that does not pretend the payment has already been missed?
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first