Funding delay prediction and proactive communication

The usable output is a customer-facing delay warning that names the inbound rail and the hold (in language a human or a template already approved) and that never states funds are available. If the model cannot produce that cite, do not send. A predicted weekday with no scheme basis is not quality. It is a new complaint.

Payments ops and digital CX should treat this as quality control on inbound funding, not as a status ping for its own sake. The customer already sees a pending credit in the app. What they need is which path the money is on, which hold is blocking posting, and a clear statement that the funds are not spendable yet. They do not need a date the scheme cannot meet.

Keep the warning separate from product choice. If the customer is on a slower inbound path, explain that path. Do not mix in a pitch for a faster method in the same message. Method choice belongs with funding method recommendation. This page is only the delay cite on the path they already started.

Inbound credits do not share one clock. ACH, Faster Payments, SEPA Credit Transfer, wires, card loads, and book transfers each have cutoff, return, and exception behavior. Overlay hold codes: scheme calendar, bank processing window, post-no-debit, sanctions screening, fraud lock, AML investigation, name or reference mismatch, recall, and operational maintenance. The predictor should score delay from that combination. A generic "funds in two business days" line is not a feature.

Pull posting state and reason codes from core, not from a free-text memo an agent typed last week. Temenos-class cores (and the same class of record systems) already carry scheme identifier, value date, cutoff, and hold reason. Map those codes to a closed set: calendar, bank processing, fraud, AML, exception, unknown. Unknown means no outbound. Do not let the model guess the class from the customer's name or the amount.

Cutoff and calendar are the only classes where a posting weekday might be honest, and only when operations has already locked that weekday into an approved template for that scheme and that holiday calendar. Promising a Tuesday the scheme cannot meet is the first failure mode. If Friday's inbound missed the scheme cutoff, Monday is a public holiday, and the bank's first posting day is Wednesday, the model does not get to say Tuesday because Tuesday sounds soon. If the approved template for that window does not include a weekday, the message stops at not yet available and we will notify when it posts.

Do not train the model to fill in a date when the hold is silent. Silent hold plus late posting is an ops queue item, not a customer date.

Illustrative example: a domestic faster-rail credit shows pending after Friday cutoff, with hold class scheme calendar, not fraud. The approved template names the rail, names the calendar hold, and states the credit is not available to spend. It includes a weekday only if that exact calendar template is on the books for this holiday weekend. It never says the money is ready. If ops has not approved a weekday sentence for this window, the send is the shorter cite, or it is suppressed.

An LLM can assemble a first draft from rail display name, hold class, and last posting event. It must not invent a clearing time, a "usually by end of day" clause, or any sentence that implies the funds have posted. Generation is a draft step. Publication is a template or a human gate.

Keep a library of approved sentences keyed by hold class and rail family. The model selects a template ID and fills only allowlisted slots: product nickname, last four of the account, rail display name, hold display name. Dates, availability verbs (cleared, available, ready to spend, in your account), and scheme cutoff times are either locked in the template or omitted. Salesforce-class CRM journey tools can send the selected template once core has written the cite onto the case. They should not let the model write a fresh body at send time.

Quality check before send: the rail is named in approved language; the hold is named in approved language; there is no availability claim; there is no weekday unless the template for that calendar window includes it; the channel matches the customer's preference; and the case is not already open from an inbound contact.

If legal or ops has not approved fraud-hold wording that does not read like a holiday delay, do not send a fraud-hold message. Silence is better than the wrong script.

The point of prediction is to reach the customer while the credit is pending and before they open chat or call. Watch the contact-center case for that inbound reference. If an agent is already on the interaction, or a case opened inside the lookback window your ops team defined, suppress the outbound. Sending the SMS after they already called is the third failure mode: two voices, two explanations, one complaint.

Recommended sequence: core posts a pending credit; delay score crosses the threshold you set for that rail and hold class; the cite is assembled from rail and hold; the template is selected; CRM checks open cases and recent contacts; send or suppress; the agent desktop shows the same cite. If the customer then calls, the agent reads the same rail and hold, not a paraphrase.

Suppression also covers journeys that already messaged about a stuck first fund during onboarding. Do not stack a delay warning on a drop-off nudge in the same window. Coordinate with onboarding abandonment prediction so the customer gets one accurate status, not two competing ones.

The second failure mode is using the bank-holiday template on a fraud hold. Calendar language (weekend, public holiday, scheme closed) on a first-party or mule review tells the customer the wait is mechanical. It is not. Fraud and AML holds need copy that does not disclose typology, does not accuse, and does not promise a posting day. Often the right customer message is a narrow review notice with a case number, or no message and an agent-owned callback.

Delay prediction must read queues it does not own. If first-party fraud detection at first deposit or AML case disposition at funding holds the credit, do not race them with a scheme-calendar SMS. A delay that is actually a sensitive hold should never generate holiday language.

Routing by class: AML disposition in progress, suppress copy that implies the bank is only waiting on the rail. Fraud lock, suppress holiday language entirely. Exception or recall, cite the exception class only if that sentence is approved; otherwise silence. Calendar and cutoff, this is the only class where a posting weekday might appear, and only from the approved calendar template.

Temenos-class core is the source for posting state and hold codes. Salesforce-class CRM is the source for journeys, cases, and already-contacted. Neither should invent the cite. If core says not posted, the app, the SMS, and the agent script say not posted. If a later posting event clears the hold, cancel queued warnings. Do not let a delayed queue fire a delay warning after the credit has already posted. If you send a follow-up, use only the approved posted template, and only if that template exists.

Ops runbook: review false delay scores (especially returns and repairs that reverse after you warned), template change control, and a kill switch when a scheme outage would make every inbound look delayed. CX runbook: agents search by inbound reference and read the same cite the customer received. If the customer did not receive one, the agent does not invent a Tuesday either.

The quality bar stays narrow on purpose. Predict from rail and hold. Warn with a cite someone already approved. Never imply the funds are there until core says they are.