Pre-closure churn interception
Graph ML detects closure-intent signals, such as competitor ACH transfers and declining transaction frequency, 60 to 90 days early and triggers a retention offer.
Banking processAcquireOnboardOpenFundTransactServiceReviewClose
By Don, DoneThat’s AI coach · updated
Score intent into a cited queue, not a mailed offer
Pre-closure interception is a review workflow. Graph and behavioral models can surface customers whose activity looks like they are preparing to leave. A retention or CX specialist then decides whether any outreach is appropriate. The model does not send the offer.
Treat the lookback window as a design choice, not a proven lead time. Many books score a 60 to 90 day horizon because that is long enough to assemble a human conversation and short enough that the signals still relate to a possible close. Do not report that window as a measured result unless your own backtest says so.
The quality bar is a queue with cites: which counterparties received ACH, how transaction frequency changed, which products are still open, and which policy flags already apply. Salesforce-class CRM and Temenos-class core systems typically hold the relationship, product, and case records you will join. Neither class of system is the model.
If the score cannot name the evidence, do not route the customer.
Separate durable signals from one-off money movement
Closure intent is a pattern, not a payment. Competitor ACH or faster-payment outflows can be a genuine signal when they repeat, grow, or coincide with falling inbound credits and thinner card or bill-pay activity. A single transfer to another bank is often a house purchase, a family gift, or a one-off savings sweep. Scoring that as churn fills the queue with people who are not leaving.
Graph features only help when an agent can check them. Useful structure includes a new outbound relationship outside the usual counterparty set, outflows concentrating toward known deposit-taking institutions, and a drop in inbound payroll or benefit credits. Pair those with simple counts: fewer settled transactions over successive cycles, cards that went dormant, products that stopped receiving standing orders.
Do not treat early arrears prediction as a substitute. Missed payments and closure intent can coincide, but collections contact is a different conversation from retention. If the customer is already in a hardship or arrears path, route there first. A retention offer that ignores arrears conflicts with forbearance and sounds careless.
Watch the one-off transfer. If the graph lights up because a customer sent a large ACH to a competitor once, require a second independent signal before the row appears: declining frequency, product dormancy, or a new standing order out. One spike without a second cite stays off the list.
What an agent should see before they pick up the phone
The queue row is the work product. Each item should show the customer identifier, open products, cited signals with dates, why the score fired, existing cases, extra-care or vulnerability flags, and a next action that is a review, not a scripted sale.
One walk-through, not a result: a current-account holder starts sending monthly ACH to another retail bank, card spend thins over two statement cycles, and a savings product that used to receive standing orders goes idle. The graph names the new counterparty as a deposit-taking institution and the frequency drop as a second cite. The row lands with a retention specialist. They check that no close request exists, that the customer is not in a collections or vulnerable-customer protocol that forbids unsolicited sales contact, and that any offer would apply only to products they hold. If those checks fail, the row is closed as do-not-contact with a reason. If they pass, the specialist chooses a conversation, not an email blast.
Do not auto-mail. An automated offer fires on stale data, misses a close already in flight, and cannot adapt for a vulnerable customer. A sales script in that situation is a conduct failure. If you must reach people at volume, keep the send under human or tightly supervised approval, and keep the copy as a service conversation about the cited change in activity.
Cites must be readable. A bare graph score is not a cite. Named counterparties, dates, frequency change, and open-product state are.
Match the offer to holdings, eligibility, and vulnerability flags
If you reach out, the offer has to be true of the book. Do not email a mortgage rate exception to a customer with no mortgage. Do not waive a fee on a product that is already closed or already in a close journey. Do not imply a packaged account, insurance, or credit line they do not hold.
Build the offer from core product inventory, eligibility rules, and any existing concession. Fee waivers, rate reviews, and service fixes only belong on the ticket if the cited product is open and the customer qualifies. A fee waiver on an already-closed path is worse than silence: it shows you did not look at account state.
Vulnerability is a stop, not a targeting attribute. If the customer is flagged for extra care, bereavement, mental-health support, or a similar protocol, do not put them on a sales script. Suppress the row or route it to the specialist team that already owns that relationship, cites attached, no recommended save package. Treating distress as a churn campaign fails a conduct review.
Keep the conversation optional. Ask whether something on your side is broken, fees, service, a product they no longer need, and whether a change they already qualify for would help. Do not stall an exit.
Do not intercept a close the customer already confirmed
Once the customer has asked to close, and that request is valid under your close process, they must be allowed to leave. Pull them from this queue. Do not insert a retention call into a confirmed close, do not delay the close to keep them, and do not send a win-back style offer while the close is still executing.
Join the intent score to close cases, branch instructions, and digital close journeys. A high score plus an open close request is not an interception candidate. It is a customer who already told you the outcome. Route that record to closure reason classification so the book learns why they left, not so someone tries a last save.
Auto-offer systems fail here. A model trained on pre-request behavior will keep scoring after the request is filed. If the workflow cannot see the close case, it will propose a fee waiver or a product they are in the act of ending. Gate the queue on no confirmed close in progress. Make that gate a hard filter.
If the customer pauses a close or asks to stay, that is a different ticket: reopen under the close team's rules, then consider retention. A paused close is not a green light for campaign copy.
After they leave, classify reasons and time any later contact
Pre-closure work stops at the door. Customers who complete a close belong on post-close processes. Use closure reason classification to tag why the relationship ended. Use winback timing prediction and churn-to-win-back targeting when policy allows later contact. Do not keep a closed customer in the interception queue, and do not reuse the pre-close offer as a win-back email.
Measure this workflow on queue quality, not on inferred days saved. Track, on your own book, the share of queued rows an agent agrees were true intent, the share suppressed for close-in-progress or vulnerability, the share of offers that cited an open eligible product, and complaints tied to contact. Do not claim a 60 to 90 day early-warning result unless you measured it on held-out closes with a defined label. The horizon is how far ahead you chose to score.
Start with a thin join: core product state, payment graph features you can explain, CRM cases including close and vulnerability flags, and a human queue.
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. This one is rated high effort to implement, so the baseline matters more than usual.
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