Risk-tiered onboarding routing

A risk-tiered onboarding route is a documented decision at application: this file may complete without a human after mandatory screening, or it must enter a review queue. The tier chooses handling intensity. It does not decide product eligibility, credit, or whether the bank will take the customer.

Quality on this control is a recorded tier plus a cite an analyst can read. The cite names the policy features that fired, the rule or model version that mapped those features to a tier, and the resulting route (STP after screening, or queue). Without that trail, operations cannot challenge a wrong route, compliance cannot sample why STP happened, and model risk cannot reconstruct what the classifier saw.

Two constraints sit on every design. A low tier does not skip sanctions screening, PEP screening, or other checks the bank has written into onboarding policy. A high tier does not auto-decline. High risk means more eyes, more evidence, and sometimes enhanced due diligence. Decline remains a separate, attributable decision after screening and, where required, human review.

Routing and screening often live in different systems. Onboarding cores, CRM case desks, and AML screening stacks (Temenos, Salesforce, NICE Actimize among platforms banks already run) do not share a single meaning of risk. If the case system treats a High code as reject, or screening treats STP as skip lists, the bank has rewritten policy in software.

Start from the feature set already in CDD policy, not from a model score nobody can map to a rule. Typical inputs: residence and tax footprint, product and expected activity, occupation and source-of-wealth flags, ownership complexity for legal persons, channel and identity-evidence quality (including whether liveness and deepfake detection passed or failed), and material gaps on the application. Give each feature a documented bucket or weight. The classifier, whether rules, scorecard, or ML, maps the vector to tiers the operating model already uses: low (STP-eligible after screening), medium (standard CDD queue), high (EDD queue). Do not keep shadow grades that only the model understands.

The assignment must be replayable. Store the feature snapshot at submission, not a live re-query that can change overnight. Store the model or rule version. Store the tier label the policy book uses, not an internal numeric score alone. If the model outputs a probability, policy defines the cut points that turn it into a tier, and those cuts belong in the cite.

Take one working example. A salaried resident applies for a basic current account, with a matching identity pack, a domestic address, no complex ownership, and a complete application. Policy features sit in the low bucket. The classifier assigns Low, the cite lists those features and the cut, and the route is STP after mandatory screening. The same product, applied for by a non-resident director of a multi-jurisdiction holding company with an incomplete source-of-wealth narrative, fires High. The route is the EDD queue. High does not decline the account. It only withholds STP and requires a human to finish CDD.

If a feature is missing, do not treat missing as low. Missing occupation, missing expected activity, or a failed identity check is a reason to raise the tier or force the queue, according to policy. The cite should say the feature was absent rather than omit the row.

Once the tier exists, this use case has two lawful destinations: continue on the STP path after screening returns an allowable result, or create a work item in the manual review queue with the cite attached. Do not add a third destination that is auto-reject from the tier. Product decline, fraud decline, and financial-crime decline each need their own policy owner and evidence.

STP means the journey can complete without an analyst writing a CDD narrative, once every mandatory control on that path has returned an allowable result. It does not mean skip controls. Queue means a human must confirm identity, purpose, source of funds or wealth, ownership, or residual screening alerts before the account is opened or funded. Work allocation can still be automated. The requirement for a human cannot be implicit.

Wire the route into the same sequence that already runs KYC steps. agentic KYC orchestration is where you enforce that Low is eligible for STP only if screening outcomes are clear. Publish destination, tier, and cite as fields on the case, not as a buried log line. Analysts on the queue need to see which features drove High so they spend time on residual risk rather than reverse-engineering the model.

Opening the account is not the last financial-crime decision. AML case disposition at funding still applies if alerts appear at first funding. A Low onboarding tier is not a standing waiver for later alerts.

Sanctions, PEP, and any other list screening the bank has designated as mandatory run for Low, Medium, and High. Where policy requires adverse media at onboard, that work sits on the path, not as an optional extra for High only. adverse media screening is how those hits should be evidenced. STP may continue only when those screens return no unresolved hit under the bank's match and materiality rules. A possible PEP or sanctions match is a queue event, even if every other feature was Low.

Treat screening as a gate, not as a feature inside the classifier. A new applicant's lists are queried as a control, in parallel with or after tiering, and STP cannot complete until that control is done. Do not encode "Low implies skip PEP" in the screening engine to save latency. That turns a routing optimization into a control gap.

Identity evidence follows the same rule. A Low-tier applicant still needs the identity standard the product requires. Failed liveness or a deepfake-risk flag is not something STP absorbs. It raises handling, usually by forcing the queue, even if other features looked Low.

After booking, the onboard tier is a snapshot, not a perpetual CDD grade. perpetual KYC refresh retiers when behaviour, ownership, or list status changes. Do not freeze Low because onboarding STP succeeded.

Three production failures look like successful automation until someone samples the file.

STP that skips PEP or sanctions. The tell is Low-tier journeys that complete with missing screening timestamps, a bypass flag, or PEP and sanctions deferred to a batch that never blocks account opening. Treat a missing screening completion as a hard stop. STP cannot fire on a null screening result. Sample Low STP files for presence of list-check evidence, not only for absence of alerts.

Using the tier as a decline. The tell is High mapped to a decline code in the onboarding core or CRM, applicants who never reach an analyst, and MI labelled high-risk rejects with no CDD narrative. High may only mean the EDD queue or its equivalent. Decline reasons stay in fraud, credit, product, or confirmed financial-crime policy, each with its own cite. If capacity is the real constraint, that is staffing and SLA, not a model output.

Hiding the cite. The tell is a case that shows only Route: STP or Route: Review, with no feature list, no version, and no policy reference. Analysts cannot challenge a Medium that should have been High, and QA cannot tell a correct Low from a truncated feature vector. Make the cite a first-class field: features, version, tier, destination, timestamp. Queue UIs must show it without a specialist tool. Challenge is a recorded action: accept the route, override with a reason, or send back to retier.

If any of those three appear, stop treating the classifier as a quality control. It is a router. The router has been allowed to rewrite policy.