Real Time Decisioning

Instant eligibility, limits, pricing and risk decisions

A timely decision with a controlled effect

Real time decisioning produces an outcome within the time needed by a live journey. Examples include payment authorisation, login risk assessment, a price quote or credit referral. These decisions have different inputs, deadlines and legal effects. There is no universal latency target for all banking decisions.

Separate the recommendation, authorised decision, committed business effect and customer message. A score can suggest a limit without changing the account. An approval response may still require acceptance or fulfilment. The user interface should state the actual status rather than interpreting every positive API response as a completed transaction.

Inputs and policy boundaries

Define required features, authoritative sources, acceptable freshness and behaviour when inputs are missing. Use the information available at the decision time; later corrections can matter for review but should not be silently substituted into the historical record.

A decision joins current evidence and policy, then records and applies an authorised outcome.

Policy rules can constrain a model's output through limits, eligibility or mandatory referrals. Resolve competing actions explicitly: a proposed limit increase should not bypass a current restriction. Model confidence is not legal authority, and a technically available input is not necessarily permitted for the decision purpose.

Timeouts, retries and concurrency

Allocate a time budget across data access, policy, scoring and write-back. Define fallback outcomes appropriate to the risk: refer, use a validated degraded route, hold or decline according to policy. Failing closed is not a universal answer for every service; failing open is not a universal continuity policy.

Preserve a business request identity across retries and reject conflicting reuse. If a response times out after a limit change committed, the caller should enquire about the original result rather than applying another increase. Coordinate concurrent changes using suitable transaction, version or state checks.

Explanations and review

Record the important inputs, model and policy versions, resulting reason codes and effect reference under an appropriate retention policy. Historical review should distinguish what the system knew from what became known later. Retaining evidence does not require promising exact deterministic replay for every stochastic or changing external dependency.

Customer notices need the reasons and rights required for that product and jurisdiction. In US credit, the Regulation B interpretation explains that adverse-action reasons must reflect the actual principal factors considered or scored. A generic model label does not supply those reasons.

Worked example: an uncertain limit update

In this fictional service, an authorised limit update reaches the account system, but the response is lost. The app shows the result as unconfirmed and enquires using the original request reference. It discovers the committed limit and presents that outcome without submitting another increase.

If a fraud restriction arrived concurrently, the effect-boundary checks would prevent an incompatible update under the stated policy. Reviewing only the earlier score would miss that state change. Tests therefore include timing races, stale data and failure after commitment.

Monitor the decision service

Track latency distributions, input failures, referrals, decisions, effect failures and customer harm. Join decisions to subsequent outcomes using the appropriate observation window. Monitor model drift and policy changes without treating every decline as a defect or every approval as success.

Rehearse degraded operation and return to normal. Pending decisions and unresolved effects need owners and reconciliation; a green availability dashboard cannot close them by itself.

Takeaway

Fast decisioning requires controlled inputs, authority, failure behaviour and business effects. A decision is useful when its status can be explained and its consequences can be operated safely.

Continue to Alternative Data.