Funding method recommendation

The model's job is to order funding methods the customer is already allowed to use, not to pick a channel the bank prefers. Card, bank transfer, and open banking pay-in complete at different rates for different people. Those rates only matter after eligibility is true.

Eligibility is a product and compliance fact. Ranking is a prediction. Mixing them produces two failures: a recommended rail the customer cannot use, or a hidden rail they can use and might still prefer.

A recommendation is a suggestion about how to start a fund. It is not evidence that money has arrived. Settlement, ledger credit, and funded status stay on the payment and core systems.

Open banking aggregators, account-linking providers, and core banking platforms (TrueLayer, Plaid, Temenos, and peers) typically supply connectivity, account status, or product eligibility. They do not replace first-party completion history, and they do not decide which options you show.

Build the eligible set before you score anything.

Start from the product being funded. A current account, savings pot, card repayment, or wallet each has a rail policy: card allowed or blocked by amount, bank transfer allowed or not, open banking pay-in allowed only when the payer bank is on the connected scheme and consent is valid.

Then apply customer-level checks. For card: a usable instrument or a real add-card path, issuer and 3-D Secure support, amount inside limits, no product ban. For bank transfer: a visible pay-in reference plus sort code or IBAN, amount inside limits and name-check. For open banking pay-in: a connected bank, valid consent, and headroom inside scheme caps.

If a check fails, the rail is not eligible. Do not rank it. Do not recommend it as a workaround. Showing "Pay with open banking" to a customer whose bank is not on the rail is a quality failure, even if the model is sure that rail would have completed had it been available.

If a check passes, the rail stays in the list. Do not drop it because another channel has a higher predicted completion rate.

Onboarding context can change emphasis, not eligibility. A customer still in onboarding abandonment prediction may need a simpler first fund. That can change which eligible rails you highlight. It does not make an ineligible rail eligible.

Once the eligible set is fixed, rank those methods by the chance the customer will finish the fund on that rail.

Use first-party history as the primary signal: which eligible methods reached a true completed credit for this customer, or for similar journeys. Completed means money on the ledger, not a click, not a redirect, not a payment-initiated webhook that later failed.

Useful inputs when you have them: prior completed funds by rail (including retries); initiated-but-not-completed attempts (abandoned 3-D Secure, unpaid pay-in references, expired consents, bank-app timeouts); session context you already collect (app vs web, first fund vs returning), used only as features, not as a reason to hide a rail; amount of this fund, because a small card load and a large transfer are different jobs.

Do not let a global default that "card converts better" overwrite a customer who has never completed a card payment and routinely finishes bank transfers. An aggregate prior is useful when history is thin. It is a poor override when history exists.

When history is thin, such as a first fund after digital onboarding, fall back to a cohort you can defend: same product, same country, same rail eligibility, similar amount band. Record that the rank is a cohort prior, not a personal track record.

Score completion, not click-through. A tap that fails 3-D Secure did not complete. A copied pay-in reference with no inbound credit did not complete. An open banking authorization the payer bank later rejects did not complete. Train and evaluate on the credit event you already trust in the ledger.

The ranked list is an order, not a filter.

Present the model's top choice as the default or highlighted path. Keep the other eligible methods on the same screen, or one tap away, with the same operational copy you would show if there were no model. If bank transfer is eligible, it stays visible even when the model prefers card. Hiding bank transfer because card converts better forces the model's favorite and strands customers whose card will not complete.

Customers pick an unhighlighted method for reasons the model cannot see: payroll only pays by transfer, they refuse to store a card, their open banking bank is in maintenance, they want a paper trail. They must still reach that method without a collapsed other-methods drawer that looks like an error.

Do not relabel a hidden rail as unavailable. Unavailable is for eligibility failures. If you marked it eligible, it is available.

If you test sort order or defaults, hold eligibility constant.

Treat the recommendation and the fund as two different states.

After the customer selects a method, the journey is still in progress. Card waits on authorization and, where used, authentication. Bank transfer waits on an inbound credit that matches your reference and amount. Open banking pay-in waits on payer-bank execution and your incoming-payment confirmation.

Do not mark the account funded, do not release a dependent feature, and do not close a funding task because the customer followed the recommendation. Selected recommended method is a UX event. Funds received is a payment event.

This split also protects work that runs on the same journey. Funding delay prediction and proactive communication needs a clock that starts from a real initiation or an expected credit, not from a ranked suggestion. First-party fraud detection at first deposit and mule account detection at top-up need the actual rail, amount, and counterparty, which you only know after the customer pays. AML case disposition at funding should fire on the credit and the source of funds you observed, not on the model's preferred channel.

If a recommended rail fails after selection, return the customer to the full eligible list. Do not call it abandoned funding until you know they left the journey.

A new current-account customer reaches the first-fund screen. The product allows card, Faster Payments bank transfer, and open banking pay-in. They have a debit card that passes issuer and amount checks, their payroll bank is on open banking with valid consent, and they can pay by transfer.

Eligibility includes all three rails. The model has no personal completion history, so it uses a first-fund cohort for this product and country. That cohort ranks open banking pay-in first, card second, bank transfer third.

Correct behavior: highlight open banking pay-in as the default, keep card visible, and keep bank transfer details on the same page (reference, account name, sort code or IBAN).

The same screen fails if you do any of the following.

Hide bank transfer because the cohort says card and open banking complete more often. The customer who will only pay from payroll by transfer then stalls, which looks like onboarding drop-off rather than a missing rail.

Recommend open banking pay-in when the customer's bank is not on the connected set. The button fails or dead-ends. The model stated a preference and ignored eligibility.

Treat the open banking authorization screen, or a card 3-D Secure challenge, as funds received, then tell the customer the account is ready. The credit has not posted. Delay messaging, fraud checks, and AML disposition then run on a fund that does not exist.

The product owner test: for a given customer and amount, can you print the eligible rails, the ranked order, and the evidence (personal history or named cohort)? Can the customer still see every eligible rail? Does funded wait for the ledger credit? If any answer is no, do not ship the recommendation.