Real-time pre-approval at point of intent

An in-session pre-approval is a credit decision that happens to render on a website or in an app. If the eligibility service did not return an actual approve, refer, or decline for a named product, do not display anything that looks like an offer. A propensity score, a segment flag, or a "likely to convert" rank is not an underwrite.

Hold the page to the standard a banker would use at a desk. Name the product the visitor was considering. Show the limit the underwrite produced, or say plainly that a limit will be set after further checks. Repeat the caveats a human would say out loud: subject to identity verification, subject to completing the application, subject to the product terms, not a promise of funds. Do not invent a round number because the hero tile has an empty amount field.

That standard removes the most common quality failure in this pattern: presenting a sample or catalogue "typical" limit as this visitor's limit. Sample figures belong in explainer copy. They do not belong in pre-approval chrome.

Peak intent is visible in the session without treating a page view as permission. Useful signals include dwell on a specific product page, interaction with a rate table or fee line, use of an affordability or rewards calculator, comparison of two variants in the same product family, and return to a saved application. Those signals justify one action: a call to the eligibility service you already run. They do not justify a hard credit search, a pre-checked consent box, or an offer for a product in another family.

Keep propensity-to-open scoring upstream if you use it. Propensity ranks who is worth a decision call. It does not decide. When the two models share a banner, teams start printing "pre-approved" from a marketing score.

Consent is a separate event from intent. Opening a credit card page is not permission to run a hard search. If the eligibility path needs a bureau enquiry the visitor has not authorised, do not call that path. Use a soft search where policy allows it, or wait for an explicit prompt that names the search type and the product. Skipping hard-search consent to keep the journey short is a control failure, not a UX win.

The same gate applies in chat. A flow that qualifies interest through conversational lead qualification still has to land on the eligibility service and on a named consent step before any search that would show on a credit file.

Do not build a second underwrite for digital. Send the in-session request to the origination decision that already exists for that product: same policy version, same product code, same decline and refer reasons. The site or app detects intent, attaches identifiers you already trust (an authenticated customer, a known device bound to that customer, or an anonymous token that cannot mint a limit), and waits for a response.

Bureau and decisioning providers such as Experian, journey and CRM layers such as Salesforce, and origination or core platforms such as Temenos commonly sit in this stack. Treat them as a class of systems, not as a ranked shortlist. The website should call the path you already operate and accept that path's payload. The CRM does not compose a credit limit. The personalisation engine does not pick a product the decisioning service did not name.

Non-decisions are not offers. Timeouts, policy-not-found, insufficient data, and "please apply in full" mean the visitor sees the ordinary product page. Do not fill the gap with an optimistic banner while a retry runs in the background.

A thin-file or new-to-bank customer may still receive a real decision: a conservative limit, a refer, or a decline with a reason code. Front-end defaults have no role here. Limit construction for sparse files belongs with thin-file credit limit calibration.

Log the correlation. Store the decision identifier, policy version, product code, and display payload you rendered. If a complaint arrives, you need to show that the tile matched the underwrite, not that a designer chose a nice number.

Map response fields to the UI one to one. Product name from the decision. Limit from the decision. Rate or rate band from the decision. Offer expiry from the decision. Caveats from the decision, plus the statutory and policy lines a banker would add in person.

If the service approves without a limit, the page says the visitor is eligible to continue an application. It does not display a facility amount. Filling that gap with a catalogue maximum, a segment average, or a layout placeholder is how sample-limit incidents start. If the service returns a limit for product A while the visitor is reading product B, do not swap the tile to "help" them. Show nothing, or state that a different product was assessed and let them open that page. Surfacing a product the visitor did not view, even when the underwrite is real, trains people to treat banners as bait.

Take a concrete session. An authenticated customer opens a rewards card page, adjusts the spend calculator, and pauses on the foreign-transaction fee. That is enough to request a decision for that card only. The eligibility service returns an approve, a specific credit limit, a purchase-rate band, and a condition that identity must be reconfirmed. The page shows those four facts in that product's chrome, with the same "subject to verification and terms" language a banker would use. It does not add a higher "up to" figure from the brochure. It does not add a personal-loan tile because another model also scored that product well. If the service had returned a refer, the page would remain the ordinary product page and invite a standard application.

Legal, credit, and product own the template together. Offer chrome is allowed only when the decision status is an actual approve, or the exact refer treatment your written policy allows to display. Design does not keep a parallel optimistic variant.

Click-through starts origination. It does not finish marketing. The pre-approval is permission to begin the application with a decision already on file. Identity, address, and any source-of-funds checks still run. Do not treat a browse as KYC, and do not skip steps because the banner already said pre-approved.

Pass the accepted offer into the onboarding path you already run. Agentic KYC orchestration can sequence document capture and identity calls after the click. Risk-tiered onboarding routing can send a known customer down a lighter path and a new-to-bank applicant down a fuller one. Both run after the visitor consents to proceed, not because they scrolled a rate table.

Expiry and change of circumstance still bind. If the visitor returns after the decision has lapsed, call eligibility again. Do not restore a stale limit from session storage. If they switch product, call again for that product. Caching a number across pages is the same defect as printing a sample limit.

Staff scripts should match the page. If a contact-centre agent can quote a different "indicative" amount, you have two underwrites. Train the desktop and the site off the same decision record.