Skip to main content
DoneThat

AI Adoption GuideBankingAcquire

Propensity-to-open scoring

ML model scores prospects on account-opening likelihood using open banking, bureau, and behavioral signals to prioritize outreach.

Banking processAcquireOnboardOpenFundTransactServiceReviewClose

By Don, DoneThat’s AI coach · updated

What the score is allowed to change

A propensity-to-open score ranks consented prospects by how likely they are to complete an account opening if a human reaches them. It changes call order on the outbound and branch list. It does not change eligibility, a limit, or permission to offer a product the person did not ask for.

The model should return three things only: a rank, a small set of openable cites, and a next action that is always a human contact (call, branch appointment, or callback). Anything that looks like a credit decision, a packaged offer, or a pre-approval belongs in a different control.

Sales ops usually inherit a pool too large to work fairly. Without a rank, the team works recency, last-touch, or whoever sits nearest the branch. A score with cites tells a caller why this name is next, which is what a branch lead needs before they will trust the Monday list.

A high open-likelihood is not evidence the person can repay, pass KYC, or sit in a cheap risk band. Mixing those jobs trains staff to treat a marketing rank as a green light.

Signals you can score without collecting more data

Score only people who consented to this use of their data, and only on attributes the bank already holds. Do not pull a new bureau file, a new open-banking connection, or a broker enrich because the campaign wants a longer list.

Inputs sit in three families you already run.

Bureau attributes already on file from Experian, Equifax, or TransUnion: file presence, thin-file versus established, recent searches the customer authorized, and any other field your privacy notice already covers for marketing contact. That is a snapshot you were allowed to keep, not a new credit decision.

Open-banking or payment-connection attributes already linked through providers such as Plaid or TrueLayer: income cadence, account tenure elsewhere, balance-stability ranges the model is allowed to use, and signs the person already shops around for banking. Use them only if the customer connected the source and the stated purpose includes this ranking.

First-party behavior: started-but-abandoned applications, product pages viewed after login, calculator use, appointment no-shows, and prior outbound outcomes. These often separate people who will pick up and finish from people who were only browsing, and they never required a third party.

If consent is missing, expired, or limited to service messages, the person does not enter the model. Scoring without consent is not a gap a high rank can paper over. Drop them from the scored queue and leave them on the lawful service path they already have.

Thin files and new-to-bank names will look weak on bureau depth. Do not treat a missing bureau as a decline, and do not fetch a fresh file to plump the score. A sparse bureau cite should read as sparse, not as risk.

Cite every reason the rank moved

A rank without cites is a black box your ops lead will ignore after the first bad call. Attach a short, human-readable cite list to every scored record before it lands in Salesforce or the branch work queue.

Cites should name the signal family and the direction. Do not dump raw bureau codes onto a banker. Useful cites: abandoned current-account application after the identity step; open-banking connection shows regular inbound pay; bureau file present, no recent authorized search spike; two prior outbound attempts, last contact asked to call after payday. Useless cites: a raw probability, an opaque segment code, or a vendor reason the caller cannot explain if the customer asks.

Keep the set small enough for a short huddle. If the model cannot produce at least one openable cite, do not mark the record as priority.

Illustrative example: a regional outbound pod works abandoned current-account starts. One consented prospect sits mid-pack on recency but near the top of the propensity list. The cites say they completed funding-source selection, connected an existing account through the bank's open-banking partner, and dropped off at the branch-visit preference screen. The caller opens with that context (you were choosing how you wanted to finish the application) instead of a cold product pitch. Another name with similar recency has cites that only show a homepage visit and no application start. That name stays on the list, just not in the first wave. Neither record carries a credit limit, an APR, or permission to sell a loan they did not start.

Store cites with the score timestamp and the source systems used. If a customer challenges the call, ops must show which consented sources fed that day's rank, not a score rebuilt from later data.

Queue a human, then keep the score off the underwrite

The only automation this use case should fire is a human outreach task. Write the score and cites onto the prospect record, create a call or appointment task, and assign it by capacity: outbound pod, home branch, or the banker who already owns the relationship. Do not auto-send a product offer, pre-fill a credit limit, or change application decisioning because the marketing score was high.

Treat a high score as call-first, never as already-approved. If the customer wants the product, they enter the ordinary application. Eligibility, affordability, and onboarding stay where they belong. A true pre-approval is a different control that fires at expressed intent, with its own disclosures: real-time pre-approval at point of intent. Do not borrow that language for a propensity rank.

Train this failure mode by name. A banker sees a high open-score in Salesforce, assumes the person is "good for" a packaged current account or a lending add-on, and offers it on the call. That is an unsolicited product push. The score ranked willingness to finish an opening they already showed interest in, or consented to be contacted about. It did not underwrite them and it did not expand the product set.

Do not use this score as a stand-in for thin-file credit limit calibration or any other credit calibration. Thin-file customers can be likely to open and still need a conservative limit once they apply. Keep the models on different objects, with different owners and a different audit trail.

After the call, capture the outcome on the same record: reached, appointment booked, not interested, wrong number, or consented to a later date. Feed those outcomes back so the rank tracks contactability and completion, not a frozen bureau snapshot. A "not interested" must not sit at the top because nobody told the model.

Adjacent acquire jobs this score must not absorb

Propensity-to-open ranks inside an existing pool. It does not build the pool.

Upstream, lookalike audience generation decides who is allowed in. If that logic is loose, you will spend scarce call time ranking people who should never have been loaded. Fix the audience job first, then score.

On the live conversation, conversational lead qualification is the human's job once they are through. Cites brief the caller. They are not a script that skips identity, consent to continue, or what the person actually wants.

Once the person agrees to open, risk treatment moves to onboarding. Risk-tiered onboarding routing can change checks, journey length, and specialist handling. The propensity score should not follow them there. Drop it at application start so nobody reads "high open propensity" as "low-risk customer."

Ops-lead control: consent flag required to score; sources limited to bureau, open-banking, and first-party behavior already held; cites mandatory for the priority queue; human task is the only automation; score fields hidden from underwriting and limit screens; staff language is follow-up on existing interest or consented contact, not an approval. If any of those fail, revert the queue to a simple consented recency list until the control is fixed.

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